This was easy to implement simply by overriding IntersectionVisitor::apply(PagedLOD). My question is: Are there any opinions on whether this should be the default behavior? If it makes sense, I will submit the change; if not, no worries."
is based on suggested fix from Marco for fixing a crash due to lack of
thread safety in std::ofstream("/dev/null"); The fix is to use a custom stream
buffer that just discards all data. The implementation is also twice as fast
as the old /dev/null based approach.
calling wglMakeCurrent twice.
This bug has been reported to NVidia, confirmed and fixed by NVidia but awaits verifiaction and release if a driver which fixes this bug.
is an example). This can happen in circumstances that are not
manageable by the OSG itself (e.g. 3rd party buggy program) but one
would expect the plugin to be able to recover by returning
ReadResult::ERROR_IN_READING_FILE.
libpng provides two callbacks for warnings and errors - those are
currently unused. By default, they point to function that call exit()
or something similar (the default error callback never returns). This
patch registers the callbacks using libpng's mechanisms, makes the
warning callback emit an osg::notify(osg::WARN) message and the error
callback throw an error. The reading process is enclosed in a
try...catch block. Upon error, the memory is freed and
ReadResult::ERROR_IN_READING_FILE is returned.
"
osgViewer::GraphicsWindow::setCursor() the new cursor type is recorded
but not applied until windows sends another WM_SETCURSOR message. This
delays the application of the cursor to the next mouse event.
The attached file fixes this by setting the new cursor with a call to
::SetCursor() immediately.
"
nvidia 6 months ago and the issue is still "in progress". I've given up
waiting for them!
Platform - various Intel Windows XP SP2 PCs with various nvidia cards
including GeForce 8800 GTS and Quadro FX 4500, and various driver
versions including the latest WHQL 175.16.
I investigated your concerns about glGenerateMipmapEXT being slower than
GL_GENERATE_MIPMAP_SGIS, and for power-of-two textures, to my surprise
it is. For a 512*512 texture, glGenerateMipmapEXT takes on average 10ms,
while GL_GENERATE_MIPMAP_SGIS takes on average 6ms. Therefore I have
modified the code to only use glGenerateMipmapEXT if the texture has a
non-power-of-two width or height. I am resubmitting all the files
previously submitted (only "Texture.cpp" has significant changes since
my previous submission, I've also replaced tabs with spaces in
"Texture").
"
