JOGL Printing Error on Boot

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

JOGL Printing Error on Boot

bgroenks96
This post was updated on .
I just upgraded my lazily not up-to-date JOGL JARs and natives to the most recent stable build from jogamp-all-platforms.7z

I now get this message every time the GLContext initializes:
Info: GLDrawableHelper.reshape: pre-exisiting GL error 0x501

It doesn't appear to really affect anything, but I just want to know if I can fix it.

Also, is it necessary to call destroy() on a NEWT Window, Screen, and Display before exit?  I seem to end up with errors on exit quite often if I do this.
Reply | Threaded
Open this post in threaded view
|

Re: JOGL Printing Error on Boor

Sven Gothel
Administrator
On 01/11/2014 03:24 AM, bgroenks96 [via jogamp] wrote:
> I just updated my lazily not up-to-date JOGL JARs and natives to the most
> recent stable build from jogamp-all-platforms.7z
>
> I now get this message every time the GLContext initializes:
> Info: GLDrawableHelper.reshape: pre-exisiting GL error 0x501
>
> It doesn't appear to really affect anything, but I just want to know if I can
> fix it.

Run you application w/ debug property 'jogl.debug.DebugGL',
i.e. 'java .. -Djogl.debug.DebugGL  yourMain'

This will throw an exception ASAP when one of the GL commands
results in an error and also enabled the native debug context if available.

Use 'jogl.debug.TraceGL' for excessive GL command trace.

>
> Also, is it necessary to call destroy() on a NEWT Window, Screen, and Display
> before exit?  I seem to end up with errors on exit quite often if I do this.

Just the window itself, see the many NEWT unit tests.
NEWT uses add/remove reference on it's referenced Screen/Display
aggregations.

~Sven



signature.asc (911 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: JOGL Printing Error on Boor

bgroenks96
Ok!  I tracked down the problem using debug to being a call to glOrtho before the view dimensions had been initialized, thus resulting in 0 width/height.  Thanks Sven!

Quick question, GLAutoDrawable.resize will always be called once before display() right?  This matters for my initialization process.

I'm also still getting this output from debug:
msg Program/shader state performance warning: Fragment Shader is going to be recompiled because the shader key based on GL state mismatches.
        when 1389408264627

How do I address that?
Reply | Threaded
Open this post in threaded view
|

Re: JOGL Printing Error on Boor

Sven Gothel
Administrator
On 01/11/2014 03:49 AM, bgroenks96 [via jogamp] wrote:
> Ok!  I tracked down the problem to being a call to glOrtho before the view
> dimensions had been initialized, thus resulting in 0 width/height.
Great.

>
> Quick question, GLAutoDrawable.resize will always be called once before
> display() right?  This matters for my initialization process.

Sure, this is well documented in the API of GLAutoDrawable

>
> I'm also still getting this output from debug:
> msg Program/shader state performance warning: Fragment Shader is going to be
> recompiled because the shader key based on GL state mismatches.
>         when 1389408264627
>
> How do I address that?

Well, that is 'fine' .. i.e. merely a performance notice of the
native debug context from the driver itself. (Enabled via the DebugGL prop).

The shader may need to be recompiled when certain states changes
and this may hint you in reducing state changes etc ..

~Sven


signature.asc (911 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: JOGL Printing Error on Boor

bgroenks96
Is that when #### a bitmasked set of GL state identifiers?