Difference between revisions of "Why Instance Design"

From JogampWiki
Jump to navigation Jump to search
Line 1: Line 1:
 
The scope of this wiki page is essentially to explain why JOGL uses a instance-design instead of a static one, used by other libraries (such as Lwjgl).
 
The scope of this wiki page is essentially to explain why JOGL uses a instance-design instead of a static one, used by other libraries (such as Lwjgl).
  
The content has been taken from [http://forum.jogamp.org/Why-does-JOGL-use-Instances-of-GLContext-GL-instead-of-exposing-a-Static-API-td4034144.html this thread].
+
The content has been taken from [http://forum.jogamp.org/Why-does-JOGL-use-Instances-of-GLContext-GL-instead-of-exposing-a-Static-API-td4034144.html this thread] where Sven decided to elaborate and list the reasons behind that since many people wonder and ask why.
  
 
<h2>Then why does JOGL use Instances of GLContext / GL* instead of exposing a Static API?</h2>
 
<h2>Then why does JOGL use Instances of GLContext / GL* instead of exposing a Static API?</h2>
 +
 +
Essentially because this is how it '''should''' be planned, doing differently is a '''wrong''' design. We are all about exposing a correct API, reflecting the real implementation model / design.
 +
 +
Answer: "Isn't static invocation faster?"
 +
 +
Question:
 +
 +
- OpenGL is a state machine. It associates locks and memory references and those OpenGL rendering states.
 +
 +
In JOGL, we do track certain states, required for a functional binding.
 +
 +
- [{{SERVER}}/deployment/jogamp-next/javadoc/jogl/javadoc/com/jogamp/opengl/GLBufferStorage.html GLBufferStorage] and its private tracker is used to manage memory mapped and use-create storage.
 +
 +
- Seamless FBO handling requires us to track currently used [[{{SERVER}}/deployment/jogamp-next/javadoc/jogl/javadoc/com/jogamp/opengl/GLBase.html#getDefaultDrawFramebuffer() FBO buffer]
 +
 +
  This allows us to pipe even onscreen rendering
 +
  using FBO as required for certain machines (OSX/CALayer w/ AWT).
 +
  However, this can be utilized by user applications,
 +
  since tracking of the FBO is for free.
 +
 +
- Sharing GLContext
 +
  <http://jogamp.org/deployment/jogamp-next/javadoc/jogl/javadoc/com/jogamp/opengl/GLSharedContextSetter.html>
 +
  To allow seamless and stable context sharing,
 +
  we are required to track its actual state
 +
  to know when we are able to create the shared 'slave' context.
 +
 +
- Last but not least, GLContext performs proper locking.
 +
  User can query states and try locking,
 +
  as well as associate data to TLS.

Revision as of 13:03, 28 January 2016

The scope of this wiki page is essentially to explain why JOGL uses a instance-design instead of a static one, used by other libraries (such as Lwjgl).

The content has been taken from this thread where Sven decided to elaborate and list the reasons behind that since many people wonder and ask why.

Then why does JOGL use Instances of GLContext / GL* instead of exposing a Static API?

Essentially because this is how it should be planned, doing differently is a wrong design. We are all about exposing a correct API, reflecting the real implementation model / design.

Answer: "Isn't static invocation faster?"

Question:

- OpenGL is a state machine. It associates locks and memory references and those OpenGL rendering states.

In JOGL, we do track certain states, required for a functional binding.

- GLBufferStorage and its private tracker is used to manage memory mapped and use-create storage.

- Seamless FBO handling requires us to track currently used [FBO buffer

 This allows us to pipe even onscreen rendering
 using FBO as required for certain machines (OSX/CALayer w/ AWT).
 However, this can be utilized by user applications,
 since tracking of the FBO is for free.

- Sharing GLContext

 <http://jogamp.org/deployment/jogamp-next/javadoc/jogl/javadoc/com/jogamp/opengl/GLSharedContextSetter.html>
 To allow seamless and stable context sharing,
 we are required to track its actual state
 to know when we are able to create the shared 'slave' context.

- Last but not least, GLContext performs proper locking.

 User can query states and try locking,
 as well as associate data to TLS.