the using of GL_RENDERBUFFER_OES

[sleith]

Hi, i want to port an iphone application, and found out that they use
this function to render:

glBindRenderbufferOES(GL_RENDERBUFFER_OES, viewRenderbuffer);
[context presentRenderbuffer:GL_RENDERBUFFER_OES];

how to replace the presentRenderbuffer function in android?
Thanks for the help

[Brad LaFountain]

All of the buffer swaping is done for you, you can't really control it. You have to draw in a callback from android. Take a look at the sample 'san-angeles' from the ndk demo.

public void onDrawFrame(GL10 gl);

Also, you will want to read about the opengl view: GLSurfaceView (http://developer.android.com/reference/android/opengl/GLSurfaceView.html#setRenderer%28android.opengl.GLSurfaceView.Renderer%29)

--
You received this message because you are subscribed to the Google Groups "android-ndk" group.
To post to this group, send email to andro...@googlegroups.com.
To unsubscribe from this group, send email to android-ndk...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/android-ndk?hl=en.

[sleith]

thanks for your response
sorry i'm a 3D novice
so do you mean i don't need to use glBindRenderbufferOES or
glBindRenderbufferOES?
because on san-angeles i don't find that syntax calling.
Thanks

On Mar 5, 12:28 pm, Brad LaFountain <blafount...@gmail.com> wrote:
> All of the buffer swaping is done for you, you can't really control it. You
> have to draw in a callback from android. Take a look at the sample
> 'san-angeles' from the ndk demo.
>
> public void onDrawFrame(GL10 gl);
>

> Also, you will want to read about the opengl view: GLSurfaceView (http://developer.android.com/reference/android/opengl/GLSurfaceView.h...
> )

>
> On Fri, Mar 5, 2010 at 12:19 AM, sleith <raysle...@gmail.com> wrote:
> > Hi, i want to port an iphone application, and found out that they use
> > this function to render:
>
> > glBindRenderbufferOES(GL_RENDERBUFFER_OES, viewRenderbuffer);
> > [context presentRenderbuffer:GL_RENDERBUFFER_OES];
>
> > how to replace the presentRenderbuffer function in android?
> > Thanks for the help
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "android-ndk" group.
> > To post to this group, send email to andro...@googlegroups.com.
> > To unsubscribe from this group, send email to

> > android-ndk...@googlegroups.com<android-ndk%2Bunsu...@googlegroups.com>

[Brad LaFountain]

Correct.

To unsubscribe from this group, send email to android-ndk...@googlegroups.com.

[sleith]

ok i'll try it.
Thanks for your support :)

On Mar 5, 1:17 pm, Brad LaFountain <blafount...@gmail.com> wrote:
> Correct.
>

> > <android-ndk%2Bunsu...@googlegroups.com<android-ndk%252Buns...@googlegroups.com>

[Devnull]

Sorry for the bump and semi grave dig, but keep in mind that it is not
necessary to use GLSurfaceView: this is just a nice utility class
provided by Android. You can call eglSwapBuffers from a native
application, provided that the code executes in the correct OpenGL
thread.

> > > > > android-ndk...@googlegroups.com<android-ndk%2Bunsubscribe@googlegr oups.com>
> > > <android-ndk%2Bunsu...@googlegroups.com<android-ndk%252Bunsubscribe@goo glegroups.com>

>
> > > > > .
> > > > > For more options, visit this group at
> > > > >http://groups.google.com/group/android-ndk?hl=en.
>
> > > --
> > > You received this message because you are subscribed to the Google Groups
> > > "android-ndk" group.
> > > To post to this group, send email to andro...@googlegroups.com.
> > > To unsubscribe from this group, send email to

> > > android-ndk...@googlegroups.com<android-ndk%2Bunsubscribe@googlegr oups.com>

[Brad LaFountain]

Oh, I would be interested in seeing how this works. Exactly how would I get control of the opengl thread from native code?

To unsubscribe from this group, send email to android-ndk...@googlegroups.com.

[Devnull]

The OpenGL commands in the Java SDK are JNI calls themselves (this
much has been confirmed by an ndk developer on this group), so there
shouldn't be much to it. As far as I am aware, however, it is not
possible to completely move OpenGL into native code: The rendering
context must still be created in Java (and all of the related fun,
such as responding to pause and resume events). However, simply moving
the eglSwapBuffers into native code should be trivial.

As it stands now, if you were to just implement some JNI function that
called into your NDK application in the
GLSurfaceView.Renderer.onDrawFrame function, then the native code
executed would be running on the OpenGL thread (which is created by
the GLSurfaceView utility class).

You can see the complete implementation of the GLSurfaceView class
here: http://android.git.kernel.org/?p=platform/frameworks/base.git;a=blob_plain;f=opengl/java/android/opengl/GLSurfaceView.java;hb=HEAD

[Brad LaFountain]

On Wed, Mar 10, 2010 at 11:24 PM, Devnull <rek...@gmail.com> wrote:

The OpenGL commands in the Java SDK are JNI calls themselves (this
much has been confirmed by an ndk developer on this group), so there
shouldn't be much to it. As far as I am aware, however, it is not
possible to completely move OpenGL into native code: The rendering
context must still be created in Java (and all of the related fun,
such as responding to pause and resume events). However, simply moving
the eglSwapBuffers into native code should be trivial.

As it stands now, if you were to just implement some JNI function that
called into your NDK application in the
GLSurfaceView.Renderer.onDrawFrame function, then the native code
executed would be running on the OpenGL thread (which is created by
the GLSurfaceView utility class).

Right, this is how we're all doing it. I thought you were saying something different. As i understand it though, the ndk doesn't provide native library for the egl calls.
 

You can see the complete implementation of the GLSurfaceView class
here: http://android.git.kernel.org/?p=platform/frameworks/base.git;a=blob_plain;f=opengl/java/android/opengl/GLSurfaceView.java;hb=HEAD

I totally forgot that we have access to the source for the java side.
 
 

To unsubscribe from this group, send email to android-ndk...@googlegroups.com.

[Devnull]

Actually, it does look like you are correct, that the actual swapping
function isn't exposed...

On Mar 10, 11:46 pm, Brad LaFountain <blafount...@gmail.com> wrote:

> On Wed, Mar 10, 2010 at 11:24 PM, Devnull <rekd...@gmail.com> wrote:
> > The OpenGL commands in the Java SDK are JNI calls themselves (this
> > much has been confirmed by an ndk developer on this group), so there
> > shouldn't be much to it. As far as I am aware, however, it is not
> > possible to completely move OpenGL into native code: The rendering
> > context must still be created in Java (and all of the related fun,
> > such as responding to pause and resume events). However, simply moving
> > the eglSwapBuffers into native code should be trivial.
>
> > As it stands now, if you were to just implement some JNI function that
> > called into your NDK application in the
> > GLSurfaceView.Renderer.onDrawFrame function, then the native code
> > executed would be running on the OpenGL thread (which is created by
> > the GLSurfaceView utility class).
>
> Right, this is how we're all doing it. I thought you were saying something
> different. As i understand it though, the ndk doesn't provide native library
> for the egl calls.
>
>
>
> > You can see the complete implementation of the GLSurfaceView class
> > here:

> >http://android.git.kernel.org/?p=platform/frameworks/base.git;a=blob_...

[Brad LaFountain]

Actually, now that i'm reading the GLSurfaceView, the mystery is gone from it a bit. I'm curious if any dev can give me any advice about if i wanted to take GLSurfaceView class and modify it a bit so that GLThread is gone and i replace the rendering thread with a pthread. Then i can call out JNI to do the actual swapping. I see there is alot of synchronized management in there, to decide when to recreate the surface, but i think that can all be handled over jni. Any opinions?

To unsubscribe from this group, send email to android-ndk...@googlegroups.com.

[David Turner]

Please let me clarify a few things:

- EGL is not currently exposed through the NDK for good reasons (ABI instability), don't call it directly from native code, this could break your app in the future.

- GLSurfaceView is indeed a utility class, you can use the Java GL calls directly to handle buffer swapping instead if you want to.

To unsubscribe from this group, send email to android-ndk...@googlegroups.com.