Re: Can JOGL be used without requiring GLAutoDrawable instances?
Posted by Sven Gothel on Jul 25, 2015; 2:11pm
URL: https://forum.jogamp.org/Can-JOGL-be-used-without-requiring-GLAutoDrawable-instances-tp4034953p4034968.html
On 07/25/2015 03:25 AM, xghost [via jogamp] wrote:
> Sven Gothel wrote
> 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.
>
> Hi Sven,
>
> I agree. That's what I was doing, but in a separate RenderSystem class, which
> would internally implement the GLEventListener and simply expose a public
> method that would, in turn, cause the GLCanvas' display() method to be invoked
> (e.g. OpenGL4RenderSystem implements RenderSystem, GLEventListener // as a
> package private, only RenderSystem public, create impl using factory/manager).
> That part always seemed straightforward, though I may not have explained
> myself as well at first.OK.
Just for the record, the GLAutoDrawable/GLEventListener 'assisted rendering'
paradigm is optional, even though it is recommended.
One can always use plain GLDrawable/GLContext etc. and handle the details
manually.
>
> The part that I feel I've not found straightforward to address is that I
> /do/ want the client/user to work with shaders directly, as shown in my code
> snippet at the bottom (part of a working test class). That snippet is not
> using JOGL, but something I like is that the user/client can work with the
> shader object, 'declare' shader inputs, build the shader, set values for
> inputs, and so on, while keeping the public interface fairly simple and
> binding-agnostic. This is what I'd expect the client to work with directly,
> even after the GL instance is hidden away in a renderer class that implements
> the GLEventListener, etc.
>
> But notice that when the client asks the program to 'build()', if we expect
> that to happen immediately, instead of say, get queued as some sort of command
> (a complication I'd like to avoid), then it seems the GL instance would have
> to be exposed. I might be missing something, but it seems even the JOGL
> ShaderProgram class does this --although that's not a problem for JOGL itself.You may confuse ShaderProgram w/ ShaderCode.
The latter merely holds the source code or binary code for one shader
and _can_ be instantiated w/o a GL instance.
Yes, ShaderCode's factory create(..) methods require a GL instance (for now),
which is used to query GLSL capabilities.
This can be avoided by using the public ShaderCode constructor
and optionally the readShaderSource(..) method.
We might want to change some of ShaderCode's API, e.g. drop the GL instance.
This can only happen for our next minor release 2.4.*,
where API changes are allowed.
The ShaderCode and ShaderProgram does require the GL instance all of its
methods performing OpenGL operations, ofc.
I hope this helps a bit.
~Sven
URL: https://forum.jogamp.org/Can-JOGL-be-used-without-requiring-GLAutoDrawable-instances-tp4034953p4034968.html
On 07/25/2015 03:25 AM, xghost [via jogamp] wrote:
> Sven Gothel wrote
> 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.
>
> Hi Sven,
>
> I agree. That's what I was doing, but in a separate RenderSystem class, which
> would internally implement the GLEventListener and simply expose a public
> method that would, in turn, cause the GLCanvas' display() method to be invoked
> (e.g. OpenGL4RenderSystem implements RenderSystem, GLEventListener // as a
> package private, only RenderSystem public, create impl using factory/manager).
> That part always seemed straightforward, though I may not have explained
> myself as well at first.
paradigm is optional, even though it is recommended.
One can always use plain GLDrawable/GLContext etc. and handle the details
manually.
>
> The part that I feel I've not found straightforward to address is that I
> /do/ want the client/user to work with shaders directly, as shown in my code
> snippet at the bottom (part of a working test class). That snippet is not
> using JOGL, but something I like is that the user/client can work with the
> shader object, 'declare' shader inputs, build the shader, set values for
> inputs, and so on, while keeping the public interface fairly simple and
> binding-agnostic. This is what I'd expect the client to work with directly,
> even after the GL instance is hidden away in a renderer class that implements
> the GLEventListener, etc.
>
> But notice that when the client asks the program to 'build()', if we expect
> that to happen immediately, instead of say, get queued as some sort of command
> (a complication I'd like to avoid), then it seems the GL instance would have
> to be exposed. I might be missing something, but it seems even the JOGL
> ShaderProgram class does this --although that's not a problem for JOGL itself.
and _can_ be instantiated w/o a GL instance.
Yes, ShaderCode's factory create(..) methods require a GL instance (for now),
which is used to query GLSL capabilities.
This can be avoided by using the public ShaderCode constructor
and optionally the readShaderSource(..) method.
We might want to change some of ShaderCode's API, e.g. drop the GL instance.
This can only happen for our next minor release 2.4.*,
where API changes are allowed.
The ShaderCode and ShaderProgram does require the GL instance all of its
methods performing OpenGL operations, ofc.
I hope this helps a bit.
~Sven
signature.asc (828 bytes) | Free forum by Nabble | Edit this page |