OpenSceneGraph/include/osgViewer/api/Win32/PixelBufferWin32

75 lines
2.7 KiB
Plaintext
Raw Normal View History

2007-06-20 20:29:19 +08:00
/* -*-c++-*- OpenSceneGraph - Copyright (C) 1998-2006 Robert Osfield
*
* This library is open source and may be redistributed and/or modified under
* the terms of the OpenSceneGraph Public License (OSGPL) version 0.0 or
* (at your option) any later version. The full license is in LICENSE file
* included with this distribution, and on the openscenegraph.org website.
*
* This library is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* OpenSceneGraph Public License for more details.
*/
/* Note, elements of PixeBufferWin32 have used Producer/RenderSurface_Win32.cpp as both
2007-06-20 20:29:19 +08:00
* a guide to use of X11/GLX and copiying directly in the case of setBorder().
* These elements are license under OSGPL as above, with Copyright (C) 2001-2004 Don Burns.
*/
#ifndef OSGVIEWER_PIXELBUFFERWIN32
#define OSGVIEWER_PIXELBUFFERWIN32 1
From Colin MacDonald, "In my application I have a custom graphics context class, derived from osg::GraphicsContext, in order to give good integration with the application's GUI toolkit. This works really well. However, I need to share OpenGL texture resources with the standard osgViewer GraphicsContext implementations, in particular the PixelBuffers. This is essential for my application to conserve graphics memory on low-end hardware. Currently the standard osg implementations will not share resources with another derived osg::GraphicsContext, other than the pre-defined osgViewer classes e.g. PixelBufferX11 is hardcoded to only share resources with GraphicsWindowX11 and PixelBufferX11 objects, and no other osg::GraphicsContext object. To address this in the cleanest way I could think of, I have moved the OpenGL handle variables for each platform into a small utility class, e.g. GraphicsHandleX11 for unix. Then GraphicsWindowX11, PixelBufferX11 and any other derived osg::GraphicsContext class can inherit from GraphicsHandleX11 to share OpenGL resources. I have updated the X11, Win32 and Carbon implementations to use this. The changes are minor. I haven't touched the Cocoa implmentation as I'm not familiar with it at all and couldn't test it - it will work unchanged. Without this I had some horrible hacks in my application, this greatly simplifies things for me. It also simplifies the osgViewer implementations slightly. Perhaps it may help with other users' desires to share resources with external graphics contexts, as was discussed on the user list recently." Notes from Robert Osfield, adapted Colin's submission to work with the new EGL related changes.
2009-11-22 00:41:02 +08:00
#include <osg/GraphicsContext>
#include <osgViewer/api/Win32/GraphicsHandleWin32>
2007-06-20 20:29:19 +08:00
namespace osgViewer
{
From Colin MacDonald, "In my application I have a custom graphics context class, derived from osg::GraphicsContext, in order to give good integration with the application's GUI toolkit. This works really well. However, I need to share OpenGL texture resources with the standard osgViewer GraphicsContext implementations, in particular the PixelBuffers. This is essential for my application to conserve graphics memory on low-end hardware. Currently the standard osg implementations will not share resources with another derived osg::GraphicsContext, other than the pre-defined osgViewer classes e.g. PixelBufferX11 is hardcoded to only share resources with GraphicsWindowX11 and PixelBufferX11 objects, and no other osg::GraphicsContext object. To address this in the cleanest way I could think of, I have moved the OpenGL handle variables for each platform into a small utility class, e.g. GraphicsHandleX11 for unix. Then GraphicsWindowX11, PixelBufferX11 and any other derived osg::GraphicsContext class can inherit from GraphicsHandleX11 to share OpenGL resources. I have updated the X11, Win32 and Carbon implementations to use this. The changes are minor. I haven't touched the Cocoa implmentation as I'm not familiar with it at all and couldn't test it - it will work unchanged. Without this I had some horrible hacks in my application, this greatly simplifies things for me. It also simplifies the osgViewer implementations slightly. Perhaps it may help with other users' desires to share resources with external graphics contexts, as was discussed on the user list recently." Notes from Robert Osfield, adapted Colin's submission to work with the new EGL related changes.
2009-11-22 00:41:02 +08:00
class OSGVIEWER_EXPORT PixelBufferWin32 : public osg::GraphicsContext, public osgViewer::GraphicsHandleWin32
2007-06-20 20:29:19 +08:00
{
public:
PixelBufferWin32(osg::GraphicsContext::Traits* traits);
virtual ~PixelBufferWin32();
virtual bool isSameKindAs(const Object* object) const { return dynamic_cast<const PixelBufferWin32*>(object)!=0; }
virtual const char* libraryName() const { return "osgViewer"; }
virtual const char* className() const { return "PixelBufferWin32"; }
virtual bool valid() const { return _valid; }
/** Realize the GraphicsContext.*/
virtual bool realizeImplementation();
/** Return true if the graphics context has been realized and is ready to use.*/
2007-06-20 20:29:19 +08:00
virtual bool isRealizedImplementation() const { return _realized; }
/** Close the graphics context.*/
virtual void closeImplementation();
/** Make this graphics context current.*/
virtual bool makeCurrentImplementation();
virtual bool makeContextCurrentImplementation( GraphicsContext* /*readContext*/ );
2007-06-20 20:29:19 +08:00
/** Release the graphics context.*/
virtual bool releaseContextImplementation();
/** Swap the front and back buffers.*/
virtual void swapBuffersImplementation();
From Colin MacDonald, "In my application I have a custom graphics context class, derived from osg::GraphicsContext, in order to give good integration with the application's GUI toolkit. This works really well. However, I need to share OpenGL texture resources with the standard osgViewer GraphicsContext implementations, in particular the PixelBuffers. This is essential for my application to conserve graphics memory on low-end hardware. Currently the standard osg implementations will not share resources with another derived osg::GraphicsContext, other than the pre-defined osgViewer classes e.g. PixelBufferX11 is hardcoded to only share resources with GraphicsWindowX11 and PixelBufferX11 objects, and no other osg::GraphicsContext object. To address this in the cleanest way I could think of, I have moved the OpenGL handle variables for each platform into a small utility class, e.g. GraphicsHandleX11 for unix. Then GraphicsWindowX11, PixelBufferX11 and any other derived osg::GraphicsContext class can inherit from GraphicsHandleX11 to share OpenGL resources. I have updated the X11, Win32 and Carbon implementations to use this. The changes are minor. I haven't touched the Cocoa implmentation as I'm not familiar with it at all and couldn't test it - it will work unchanged. Without this I had some horrible hacks in my application, this greatly simplifies things for me. It also simplifies the osgViewer implementations slightly. Perhaps it may help with other users' desires to share resources with external graphics contexts, as was discussed on the user list recently." Notes from Robert Osfield, adapted Colin's submission to work with the new EGL related changes.
2009-11-22 00:41:02 +08:00
virtual void bindPBufferToTextureImplementation( GLenum /*buffer*/ );
2007-06-20 20:29:19 +08:00
protected:
void init();
bool _initialized;
bool _valid;
bool _realized;
From Colin McDonald, "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(). "
2008-03-05 00:39:44 +08:00
int _boundBuffer;
2019-09-17 17:50:42 +08:00
bool _supportBindTexImage;
2007-06-20 20:29:19 +08:00
};
}
#endif