Not a GL2 implementation exception on ARM GLES hardware.

[xranby]

Hi i tested to run glg2d on Armv7 hardware using the jogl rc6-beta
http://jausoft.com/blog/2012/02/27/jogamp-rc6-beta-linux-armv7-builds/

during glg2d unittesting i saw this:

Exception in thread "AWT-EventQueue-0" javax.media.opengl.GLException: Not a GL2 implementation
at jogamp.opengl.es2.GLES2Impl.getGL2(GLES2Impl.java:4564)
at glg2d.G2DGLSimpleEventListener.setupMatrices(G2DGLSimpleEventListener.java:70)

I think glg2d shall not just assume it's GL2 and instead use getGL2ES1 or getGL2ES2.

Cheers
Xerxes

[brandonborkholder]

That's a good point, although I'm not sure how easy it will be. A quick glance tells me I might be able to use GL2ES1 with some small modifications to my code. However, there are some features, like glPushAttrib() and glPushClientAttrib that don't exist in GL2ES1 or GL2ES2. What's the best way to manage that state in the application?

My end goal is to translate everything into shaders and leave the fixed-function pipeline. Then I can use GL2ES2. But until then, I may just need to make it more obvious that my library requires OpenGL 2.1 hardware.

[brandonborkholder]

It may be possible to manage my own attribute state using a combination of glGet* and glIs*. See http://www.khronos.org/message_boards/viewtopic.php?f=4&t=1172

I need to see if that's the only issue standing in the way of moving to GL2ES1.

[sgothel]

Are we talking about the pixel storage mode states ?
Here I have a util class com.jogamp.opengl.util.GLPixelStorageModes,
useful when you need to read/write the framebuffer etc.

We would need an abstraction for the other modes .. if required.

Can you point me to the code ?

[brandonborkholder]

That's part of what I meant. In a few places I push all attribute bits
https://github.com/brandonborkholder/glg2d/blob/42491ecebaa30787f39723d49617fa4759559945/src/main/java/glg2d/GLGraphics2D.java#L746because
I'm pushing a new Graphics2D object (and treating it like a
stack). But I see what you mean. GLPixelStorageModes could be abstracted
out to save all attribute bits.

On Fri, Mar 23, 2012 at 09:44, Sven Gothel <
[email protected]

wrote:

Are we talking about the pixel storage mode states ?
Here I have a util class com.jogamp.opengl.util.GLPixelStorageModes,
useful when you need to read/write the framebuffer etc.

We would need an abstraction for the other modes .. if required.

Can you point me to the code ?

---

Reply to this email directly or view it on GitHub:
#1 (comment)

[sgothel]

so we have it for pixel storage modes, you could derive from it - or create other GL_Modes classes for 'util' and read the GL2, GL3/4 core and ES1/2 specs to properly handle it fir the specific group.
Then we could have a GLAllMode class using them all together, in case you really need to save all modes
per default, as you do it right now. IMHO such behavior would be expensive if done many times, like
in a scene graph traversal. Its always much faster to do it when necessary only for the required set of states.
The good news is, the 'core' profiles (incl. ES2) really don't have lots of states anymore anyways :)
BTW .. thats the reason why we have impl. the client attribute stack handling in Java -> performance.
Nevertheless .. feel free to send me a pull request for the util GL_Modes handler - thank you.