search

brandonborkholder / glg2d

Graphics2D wrapper for JOGL
77 stars 31 forks source link

Not a GL2 implementation exception on ARM GLES hardware. #1

Open xranby opened 12 years ago

xranby commented 12 years ago

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 commented 12 years ago

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 commented 12 years ago

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 commented 12 years ago

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 commented 12 years ago

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 < reply@reply.github.com

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: https://github.com/brandonborkholder/glg2d/issues/1#issuecomment-4659144

sgothel commented 12 years ago

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.