[osg-submissions] osgViewer::PixelBufferWin32 updates

[Robert Osfield]

Thanks Colin, changes merged and submitted to SVN.

W.r.t the threading issue on destruction of the GraphicsContext under
Windows, I don't have any recommendations.  Its a real pain in the ass
for a multi-threaded application to have to cope with this silly
Windows constraint.  I don't even know where to start in trying to
figure out how one might ensure the right thread kills the right
window.  This is a topic of discussion on osg-users as its pretty
involved.

Robert.

On Mon, Mar 3, 2008 at 5:44 PM, Colin McDonald <cjmcdonald at qinetiq.com> wrote:
> Hi Robert,
>
>  Attached is an updated to osgViewer::PixelBufferWin32.
>
>  The win32 pbuffer implementation returned an error unless both the
>  WGL_ARB_pbuffer and the WGL_ARB_render_texture functions were present.
>  This was too restrictive, as a pbuffer can usefully be created without
>  render-to-texture, e.g. for use with glReadPixels.  The osg 1.2/Producer
>  pbuffers worked without RTT, and osgUtil::RenderStage has all the code to
>  handle both RTT and non-RTT pbuffers, doing a read and copy in the
>  latter case.
>
>  With these changes I have successfully tested the osgprerender example
>  on a graphics card which supports RTT, and one which doesn't.  Plus
>  tested in my own application.
>
>  In order to aid diagnostics I have also added more function status
>  return checks, and associated error messages.  I have included the win32
>  error text in all error messages output.  And there were some errors
>  with multi-threaded handling of "bind to texture" and a temporary window
>  context which I have corrected.
>
>  These is one (pre-existing) problem with multi-threaded use of pbuffers
>  in osgViewer & osgprerender, which I have not been able to fix.  A win32
>  device context (HDC) can only be destroyed from the thread that created
>  it.  The pbuffers for pre-render cameras are created in
>  osgUtil::RenderStage::runCameraSetUp, from the draw thread.  But
>  closeImplementation is normally invoked from the destructor in the main
>  application thread.  With the additional error messages I have added,
>  osgprerender will now output a couple of warnings from
>  osgViewer::PixelBufferWin32::closeImplementation() at exit, after
>  running multi-threaded on windows.  I think that is a good thing, to
>  highlight the problem.  I looked into fixing it in osgViewer::Renderer &
>  osgUtil::RenderStage, but it was too involved for me.  My own
>  application requirements are only single-threaded.
>
>  Unrelated fix - an uninitialised variable in
>  osg::GraphicsThread::FlushDeletedGLObjectsOperation().
>
>  Regards
>
>  Colin McDonald
>
>
> _______________________________________________
>  osg-submissions mailing list
>  osg-submissions at lists.openscenegraph.org
>  http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
>
>