Re: Can JOGL be used without requiring GLAutoDrawable instances?
Posted by Sven Gothel on Jul 23, 2015; 4:30pm
URL: https://forum.jogamp.org/Can-JOGL-be-used-without-requiring-GLAutoDrawable-instances-tp4034953p4034957.html
On 07/23/2015 07:50 AM, xghost [via jogamp] wrote:
> Hi all,
>
> I'm currently working on a project to develop a relatively small
> framework with the goal of supporting game development efforts for
> students in a course. The scope of this project is an OpenGL-based
> renderer and a 3D scene graph, and must be written in Java. (That's
> the course pre-req. for students.)
>
> I've been using JOGL for a while and have also played around a bit
> with LWJGW3 --yes, I dare disturb you by mentioning a competitor
> :D--
>
> There're some things I'd like to do, but I'm finding the requirement
> to have a GLAutoDrawable object a bit of a hassle. For example, I
> want to hide the library dependency from clients (i.e. clients use my
> interface, not JOGL directly). However, if/when needs to use a shader
> object (one I make available, not JOGL's ShaderProgram class), they'd
> need to be able to have a reference to the gl object for it to work,
> leaking the fact that I'm using JOGL through the interface.
>
> More concretely, code that looks like this example below:
>
> program.<Float> getInput("position_x").set(0.5f);
>
> would have to look, say, like this:
>
> GL4 gl = ... // get an drawable.getGL(), etc... program.<Float>
> getInput("position_x").set(gl, 0.5f);
>
> ...which is problematic; I want to avoid leaking JOGL 'knowledge' to
> the client program.As Xerxes mentioned, there is a good reason for exposing OpenGL's
dynamic instance model
<http://forum.jogamp.org/Why-does-JOGL-use-Instances-of-GLContext-GL-instead-of-exposing-a-Static-API-td4034144.html>.
You can do at least two things.
[1] Hiding JOGL details by wrapping the GL instance in an
implementation specific class, which implements a public interface.
This way, your users don't know the details .. but your implementation
has access to your inner states, at least JOGL's GL instance.
public interface APIContext {};
/** pp */ class APIState implements APIContext { final GL gl; ... }
Or .. not recommended:
[2] In case your API follows some sort of state constraints:
- makeCurrent
- user stuff w/ public API
- release
You could use thread local storage, i.e. ThreadLocal<>
~Sven
URL: https://forum.jogamp.org/Can-JOGL-be-used-without-requiring-GLAutoDrawable-instances-tp4034953p4034957.html
On 07/23/2015 07:50 AM, xghost [via jogamp] wrote:
> Hi all,
>
> I'm currently working on a project to develop a relatively small
> framework with the goal of supporting game development efforts for
> students in a course. The scope of this project is an OpenGL-based
> renderer and a 3D scene graph, and must be written in Java. (That's
> the course pre-req. for students.)
>
> I've been using JOGL for a while and have also played around a bit
> with LWJGW3 --yes, I dare disturb you by mentioning a competitor
> :D--
>
> There're some things I'd like to do, but I'm finding the requirement
> to have a GLAutoDrawable object a bit of a hassle. For example, I
> want to hide the library dependency from clients (i.e. clients use my
> interface, not JOGL directly). However, if/when needs to use a shader
> object (one I make available, not JOGL's ShaderProgram class), they'd
> need to be able to have a reference to the gl object for it to work,
> leaking the fact that I'm using JOGL through the interface.
>
> More concretely, code that looks like this example below:
>
> program.<Float> getInput("position_x").set(0.5f);
>
> would have to look, say, like this:
>
> GL4 gl = ... // get an drawable.getGL(), etc... program.<Float>
> getInput("position_x").set(gl, 0.5f);
>
> ...which is problematic; I want to avoid leaking JOGL 'knowledge' to
> the client program.
dynamic instance model
<http://forum.jogamp.org/Why-does-JOGL-use-Instances-of-GLContext-GL-instead-of-exposing-a-Static-API-td4034144.html>.
You can do at least two things.
[1] Hiding JOGL details by wrapping the GL instance in an
implementation specific class, which implements a public interface.
This way, your users don't know the details .. but your implementation
has access to your inner states, at least JOGL's GL instance.
public interface APIContext {};
/** pp */ class APIState implements APIContext { final GL gl; ... }
Or .. not recommended:
[2] In case your API follows some sort of state constraints:
- makeCurrent
- user stuff w/ public API
- release
You could use thread local storage, i.e. ThreadLocal<>
~Sven
signature.asc (828 bytes) | Free forum by Nabble | Edit this page |