Just wondering why not android.opengl.GLSurfaceView

543 views
Skip to first unread message

Ted Malaska

unread,
Jun 14, 2010, 4:11:24 PM6/14/10
to ReplicaIsland Coding Community
Just wondering, what are the main differences from the
com.replica.replicaisland.GLSurfaceView and the
android.opengl.GLSurfaceView.

Why would I use one or the other?

James Luzwick

unread,
Jun 14, 2010, 4:58:28 PM6/14/10
to replica-island-...@googlegroups.com
Chris talks about this in the Javadoc of his GLSurfaceView class.  Here is a snippet of what he says.

"Typically you use GLSurfaceView by subclassing it and overriding one or more of the View system input event methods. If your application does not need to override event methods then GLSurfaceView can be used as-is. For the most part GLSurfaceView behavior is customized by calling "set" methods rather than by subclassing. For example, unlike a regular View, drawing is delegated to a separate Renderer object which is registered with the GLSurfaceView using the {@link #setRenderer(Renderer)} call."

He might also refer to this decision in a blog post, I forgot if he did or not.

-Jim

Bart Hirst

unread,
Jun 14, 2010, 5:13:32 PM6/14/10
to replica-island-...@googlegroups.com
I think he also discusses this on the Google I/O Presentation

Chris Pruett

unread,
Jun 14, 2010, 6:43:59 PM6/14/10
to replica-island-...@googlegroups.com
Basically, I hacked up the original GLSurfaceView to solve a very specific problem: I wanted to go to different Activities within my app without throwing all of my OpenGL state away.  The major change was to separate the EGLSurface from the EGLContext, and to throw the former away onPause(), but preserve the latter until the context is explicitly lost.  The default implementation of GLSurfaceView (which I didn't write, by the way), throws all GL state away when the activity is paused, and calls onSurfaceCreated() when it is resumed.  That meant that, when a dialog box popped up in my game, closing it incurred a delay because all the textures had to be reloaded.  

You should use the default GLSurfaceView.  If you must have the same functionality that mine has, you can look at mine.  But doing what I did exposed all sorts of awful driver bugs in some handsets (see the very long comments near the end of that file), and you can avoid all that mess by just using the default one.

Chris

Ted Malaska

unread,
Jun 14, 2010, 8:17:51 PM6/14/10
to ReplicaIsland Coding Community


thanks for the response.

ok one more question. I see you used PNG image format. When I save
an image in gimp as PNG the image doesn't render on my droid. I'm
guessing this has to do with compression.

So my question to you is what tool did you save your images in and if
it was gimp how do I save the images so they'll work for the droid?

Thanks

Bart Hirst

unread,
Jun 14, 2010, 8:56:56 PM6/14/10
to replica-island-...@googlegroups.com
I had a similar problem here.  Make sure your PNG's are powers-of-2 pixels on each side.

Ted Malaska

unread,
Jun 14, 2010, 8:57:57 PM6/14/10
to ReplicaIsland Coding Community
Crazy, I just figured it out. This may be common knowledge to a
opengl guy buy this is my first time with opengl.

The images have to be the right dimensions or they don't work on the
droid.

Like 16x16, 32x32, and 512x512 work. But 24x24 and 320x480 don't.

Can some one enlighten me on why this is?

Thanks

Chris Pruett

unread,
Jun 14, 2010, 9:12:49 PM6/14/10
to replica-island-...@googlegroups.com
As Bart says, the dimensions of each side of every image must be a
power of 2. 16, 32, 64, 128, 256, 512, 1024, etc. Those that are not
might render (it's up to the driver what to do in that case) or might
fail. So make them all sized correctly and you should be good.

Chris

Reply all
Reply to author
Forward
0 new messages