Source/System/Window/Base/OGLExt.dox

   1 #include "OSGConfig.h"
   2
   3 using namespace OSG;
   4
   5
   6
   7 /*! \page PageSystemOGLObjects OpenGL Objects & Extension Handling
   8
   9     \section PageSystemOGLObj OpenGL Objects
  10     \section PageSystemOGLExt OpenGL Extensions
  11  */
  12
  13
  14
  15
  16
  17
  18
  19
  20
  21
  22
  23
  24
  25
  26 #if 0
  27
  28 /*! \page PageSystemOGLObjects OpenGL Objects & Extension Handling Foo
  29
  30 \section PageSystemOGLObj OpenGL Objects
  31
  32 OpenGL objects are an important way to manage data and speed up repetitive use.
  33 OpenGL objects in OpenSG include everything that can be stored inside
  34 OpenGL, most prominently display lists and texture objects.
  35
  36 Handling OpenGL objects in a multi-window and possibly multi-pipe environment
  37 becomes an interesting problem. As the different windows may show different
  38 parts of a scene or different scenes alltogether the actually used and defined
  39 set of OpenGL objects should include only what's necessary to reduce the
  40 consumed ressources.
  41
  42 To do that OpenGL objects are managed by the OpenSG Windows. Before they are
  43 used they have to be registered with the OSG::Window class. This is a static
  44 operation on the Window class, as it affects all exisiting Windows. Multiple
  45 objects can be registered in one call, and they will receive consecutive
  46 object ids. The ids are assigned by the object manager. It can not be queried
  47 from OpenGL, as the thread which creates the objects usually doesn't have a
  48 valid OpenGL context. As a consequence you should not use OpenGL-assigned ids,
  49 as they might interfere with OpenSGs handling of ids.
  50
  51 Part of the registration is to provide an update OSG::Functor, which is called
  52 whenever the object needs to be updated. This functor gets passed the id and
  53 status of the object and has to execute the correct function. There are a
  54 number of stati that the functor has to handle.
  55
  56 The first time it is called the status be OSG::Window::GLObjectE::initialize.
  57 The functor has to create the necessary OpenGL ressources and initialize the
  58 OpenGL object. For a texture object this is the definition of the image via
  59 glTexImage().
  60
  61 When the object changes there are two cases to distinguish. In the simple case
  62 the object has changed significantly, needing a
  63 OSG::Window::GLObjectE::reinitialize. For textures this would be changing the
  64 filter or changing the image size. Both of these actions necessitate a
  65 recreation of the actual texture object. If only the data of the image changes
  66 this can be handledmore efficiently via glTexSubImage() calls, which is an
  67 example for a OSG::Window::GLObjectE::refresh. The OSG::Window is responsible
  68 for keeping track of the current of the objects, and thus it has to be
  69 notified whenever the state of the OpenSG object underlying an OpenGL has
  70 changed, necessitating either a refresh or a reinitialize. This can be done by
  71 calling the static OSG::Window::refreshGLObject or
  72 OSG::Window::reinitializeGLObject methods. The object will be flagged as
  73 changed in all Windows and at the next validate time it will be
  74 refreshed/recreated.
  75
  76 Before an object can be used it has to be validated. This has to be done when
  77 the OpenGL context is valid and should usually be done just before the object
  78 is used. If the object is still valid, nothing happens. The
  79 OSG::Window::validateObject method is inline and thus the overhead of calling
  80 it before every use is minimal.
  81
  82 When an object is not needed any more is needs to be destroyed. The
  83 destruction can be started via OSG::Window::destroyGLObject. It will actually
  84 be executed the next time a Window has finished rendering (i.e. its
  85 OSG::Window::frameExit() function is called). The object's functor will be
  86 called for the OSG::Window::GLObjectE::destroy state, and it should free
  87 context-specific resources. After this has happened for all Windows it will be
  88 called one final time with OSG::Window::GLObjectE::finaldestroy. Here
  89 context-independent resources can be freed.
  90
  91 \section PageSystemOGLExt OpenGL Extensions
  92
  93 The situation with OpenGL extensions is similar to the one with OpenGL objects:
  94 as the thread that initializes things probably has no OpenGl context, it cannot
  95 call the necessary OpenGL functions directly. Further complicating matters is
  96 the fact that in systems with multiple graohics cards they may not all be of
  97 the same type, and thus might support different extensions.
  98
  99 To handle these situations the extensions themselves and the extension
 100 functions need to be registered and accessed using the OSG::Window. The
 101 registration (OSG::Window::registerExtension, OSG::Window::registerFunction)
 102 just needs the names and returns a handle that has to be be used to access the
 103 extensions/functions. This registration can be done from any thread.
 104
 105 When using the extension/function it is necessary to check if it supported on
 106 the currently active OpenGL context. To speed this up the Window caches the
 107 test results and provides the OSG::Window::hasExtension method to check it.
 108 To access the functions OSG::Window::getFunction method can be used. It is not
 109 advisable to store the received extension functions, as there is no guarantee
 110 that the pointer will be the same for different contexts.
 111
 112
 113
 114 */
 115
 116 #endif