Android EGL-fu

SDL Development
1

Hello guys,

Is there any particular reason to use all EGL-related calls with JNI? I’ve
dug a little bit on the AOSP code, and realized that all java egl related
classes are merely a JNI wrapper to the proper EGL C library.
This means that when SDL is p.e. flipping buffers, it will go from C to
Java to C again.

So, I moved all EGL-related SDLActivity methods to C-code only
(SDL_androidgl.c), as AFAIK all supported versions shall support the egl.h
on NDK.

Minimum API is 10 right? (from what i could see on the android-project
AndroidManifest.xml)

P.E, Android_GL_SwapWindow can be simply implemented by:
void
Android_GL_SwapWindow(_THIS, SDL_Window * window)
{
if (eglSwapBuffers(display, surface) == EGL_FALSE) {
SDL_SetError(“Error on eglSwapBuffers”);
return;
}
}

SDLActivity methods:
initEGL - createEGLContext - createEGLSurface - flipEGL

I did not benchmark it but i’m pretty sure it is more efficient as we
remove the JNI context switching overhead.
The only JNI call we will need is to update the native EGL surface, which
is recovered using ANativeWindow_fromSurface.

Is there interest on this improvement? I want to make sure it doesnt break
any feature before committing it to review.

Cheers------
Jos? Pereira

2

Is there any particular reason to use all EGL-related calls with JNI?
I’ve dug a little bit on the AOSP code, and realized that all java egl
related classes are merely a JNI wrapper to the proper EGL C library.
This means that when SDL is p.e. flipping buffers, it will go from C to
Java to C again.

This is a stupid question, but: is the EGL on Android any different from
the EGL for Pandora, or the Raspberry Pi, or Wayland or Mir (etc)?

(Beyond a few typedefs for display handles, etc.)

If this is basically all the same, I’d sorta like to move all of this to
one “egl” video target with a little bit of platform-specific glue code
for the different platform variations.

Which is to say, yes, in any case, it seems to me that less JNI is
better than more.

–ryan.

3

No difference at all, indeed a good point, we could just implement a
generic EGL glue that shall work with a lot more devices. There is a EGL
counterpart for pretty much every callback SDL supports. Only platform
dependent code shall be to create the EGLSurface (eglCreateWindowSurface)
which receives ANativeWindow as argument.------
Jos? Pereira
Personal blog http://www.onaips.com

On Wed, May 22, 2013 at 4:20 PM, Ryan C. Gordon wrote:

Is there any particular reason to use all EGL-related calls with JNI?

I’ve dug a little bit on the AOSP code, and realized that all java egl
related classes are merely a JNI wrapper to the proper EGL C library.
This means that when SDL is p.e. flipping buffers, it will go from C to
Java to C again.

This is a stupid question, but: is the EGL on Android any different from
the EGL for Pandora, or the Raspberry Pi, or Wayland or Mir (etc)?

(Beyond a few typedefs for display handles, etc.)

If this is basically all the same, I’d sorta like to move all of this to
one “egl” video target with a little bit of platform-specific glue code for
the different platform variations.

Which is to say, yes, in any case, it seems to me that less JNI is better
than more.

–ryan.

_____________**
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/**listinfo.cgi/sdl-libsdl.orghttp://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

4

2013/5/22 Jos? Luis Pereira

Hello guys,

Is there any particular reason to use all EGL-related calls with JNI? I’ve
dug a little bit on the AOSP code, and realized that all java egl related
classes are merely a JNI wrapper to the proper EGL C library.
This means that when SDL is p.e. flipping buffers, it will go from C to
Java to C again.

So, I moved all EGL-related SDLActivity methods to C-code only
(SDL_androidgl.c), as AFAIK all supported versions shall support the egl.h
on NDK.

Minimum API is 10 right? (from what i could see on the android-project
AndroidManifest.xml)

P.E, Android_GL_SwapWindow can be simply implemented by:
void
Android_GL_SwapWindow(_THIS, SDL_Window * window)
{
if (eglSwapBuffers(display, surface) == EGL_FALSE) {
SDL_SetError(“Error on eglSwapBuffers”);
return;
}
}

SDLActivity methods:
initEGL - createEGLContext - createEGLSurface - flipEGL

I did not benchmark it but i’m pretty sure it is more efficient as we
remove the JNI context switching overhead.
The only JNI call we will need is to update the native EGL surface, which
is recovered using ANativeWindow_fromSurface.

Is there interest on this improvement? I want to make sure it doesnt break
any feature before committing it to review.

Cheers

Jos? Pereira

Sounds great, post it in http://bugzilla.libsdl.org/--
Gabriel.

5

From: icculus@icculus.org (icculus)
To: SDL Development List
Sent: Wed, May 22, 2013 7:20:50 PM
Subject: Re: [SDL] Android EGL-fu

Is there any particular reason to use all EGL-related calls with JNI?
I’ve dug a little bit on the AOSP code, and realized that all java egl
related classes are merely a JNI wrapper to the proper EGL C library.
This means that when SDL is p.e. flipping buffers, it will go from C to
Java to C again.

This is a stupid question, but: is the EGL on Android any different from the EGL
for Pandora, or the Raspberry Pi, or Wayland or Mir (etc)?

(Beyond a few typedefs for display handles, etc.)

If this is basically all the same, I’d sorta like to move all of this to one
"egl" video target with a little bit of platform-specific glue code for the
different platform variations.

Which is to say, yes, in any case, it seems to me that less JNI is better than
more.

–ryan.

Ryan,

I think your assertion is correct. I found the EGL parts could be the same and
there are 2 platform specific parts. One to get the platform display and the
other for the platform window surface.

I have a small little project that basically shows this:


It support RAW framebuffer, SDL 1.2 (X) surface, and raspberry pi.

I was actually planning to incorporate this into SDL2 so that it would better
suit devices like pandora and rpi.

6

That would be great. I’d love to unify the EGL code in SDL.

Cheers!On Thu, May 23, 2013 at 7:02 AM, Scott Smith wrote:

From: Ryan C. Gordon
To: SDL Development List
Sent: Wed, May 22, 2013 7:20:50 PM
Subject: Re: [SDL] Android EGL-fu

Is there any particular reason to use all EGL-related calls with JNI?
I’ve dug a little bit on the AOSP code, and realized that all java egl
related classes are merely a JNI wrapper to the proper EGL C library.
This means that when SDL is p.e. flipping buffers, it will go from C to
Java to C again.

This is a stupid question, but: is the EGL on Android any different from
the EGL for Pandora, or the Raspberry Pi, or Wayland or Mir (etc)?

(Beyond a few typedefs for display handles, etc.)

If this is basically all the same, I’d sorta like to move all of this to
one “egl” video target with a little bit of platform-specific glue code for
the different platform variations.

Which is to say, yes, in any case, it seems to me that less JNI is better
than more.

–ryan.

Ryan,

I think your assertion is correct. I found the EGL parts could be the same
and there are 2 platform specific parts. One to get the platform display
and the other for the platform window surface.

I have a small little project that basically shows this:
http://sourceforge.net/projects/eglport/
It support RAW framebuffer, SDL 1.2 (X) surface, and raspberry pi.

I was actually planning to incorporate this into SDL2 so that it would
better suit devices like pandora and rpi.

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

7

I will start implementing in a separate EGL driver (folder). I dont have
complete knowledge on how SDL implements the video drivers, mainly how the
macro checks are working. Any recommendations?

Also, again about Android, i would say that a OpenSLES implementation could
also be very favourable for audio, however i dont have
an immediate interest on it ATM.

Best------
Jos? Pereira
Personal blog http://www.onaips.com

On Thu, May 23, 2013 at 8:43 AM, Sam Lantinga wrote:

That would be great. I’d love to unify the EGL code in SDL.

Cheers!

On Thu, May 23, 2013 at 7:02 AM, Scott Smith wrote:

From: Ryan C. Gordon
To: SDL Development List
Sent: Wed, May 22, 2013 7:20:50 PM
Subject: Re: [SDL] Android EGL-fu

Is there any particular reason to use all EGL-related calls with JNI?
I’ve dug a little bit on the AOSP code, and realized that all java egl
related classes are merely a JNI wrapper to the proper EGL C library.
This means that when SDL is p.e. flipping buffers, it will go from C to
Java to C again.

This is a stupid question, but: is the EGL on Android any different from
the EGL for Pandora, or the Raspberry Pi, or Wayland or Mir (etc)?

(Beyond a few typedefs for display handles, etc.)

If this is basically all the same, I’d sorta like to move all of this to
one “egl” video target with a little bit of platform-specific glue code for
the different platform variations.

Which is to say, yes, in any case, it seems to me that less JNI is better
than more.

–ryan.

Ryan,

I think your assertion is correct. I found the EGL parts could be the
same and there are 2 platform specific parts. One to get the platform
display and the other for the platform window surface.

I have a small little project that basically shows this:
http://sourceforge.net/projects/eglport/
It support RAW framebuffer, SDL 1.2 (X) surface, and raspberry pi.

I was actually planning to incorporate this into SDL2 so that it would
better suit devices like pandora and rpi.

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

8

Sounds like a brilliant idea, and hopefully shouldn’t be too much work.

“Video” driver is a bit of a misnomer with SDL, as they also contain the
platform-specific hooks for input and event wrangling. For that reason you
might not want to implement EGL as a whole discrete video driver per se,
but perhaps a subset of common methods that get called by the current stack
of of video drivers.

Right now, the way it works is that the top level SDL_VideoDevice struct
has pointers to the GL context handling methods in the device driver (see
http://hg.libsdl.org/SDL/file/53df899db00b/src/video/SDL_sysvideo.h#l220 ).
In the X11 driver for instance, that means _this->GL_GetProcAddress can be
set to point at X11_GL_GetProcAddress (defined in
/src/video/x11/SDL_x11opengl.c) or X11_GLES_GetProcAddress (defined in
/src/video/x11/SDL_x11opengles.c). There’s also a generic struct pointer of
type SDL_PrivateGLESData in there, which is later defined in the video
driver (e.g. /src/vide/x11/SDL_x11opengles.h) to be a container for all of
the EGL function pointers and so forth.

The tricky part is that SDL is generally not linked to WGL/GLX/GL or
EGL/GLES at compile time, but the application most likely is. And since
there’s only one set of GL context functions in SDL, and there are cases
like X11 where you can have both GLX and EGL present on the system, they
need to be pointing at the right one for the application to work properly.
For this reason there’s an SDL_GL attribute flag SDL_GL_CONTEXT_EGL, which
hints to the video driver whether to demand an EGL display and fall over if
there isn’t one.

A good place to start might be to take /src/video/x11/SDL_x11opengl.c and
try and sieve out the platform specific bits (i.e. the LoadLibrary and
GetVisual parts).

Interestingly, Canonical have been jonesing for AMD/NVIDIA to make their
Linux desktop drivers accessible through EGL. If this happens, then we
might have to do some rework to fix all the naming and remove the
assumption that EGL implies GLES.On 24 May 2013 01:01, Jos? Luis Pereira wrote:

I will start implementing in a separate EGL driver (folder). I dont have
complete knowledge on how SDL implements the video drivers, mainly how the
macro checks are working. Any recommendations?

Also, again about Android, i would say that a OpenSLES implementation
could also be very favourable for audio, however i dont have
an immediate interest on it ATM.

Best

Jos? Pereira
Personal blog http://www.onaips.com

On Thu, May 23, 2013 at 8:43 AM, Sam Lantinga wrote:

That would be great. I’d love to unify the EGL code in SDL.

Cheers!

On Thu, May 23, 2013 at 7:02 AM, Scott Smith wrote:

From: Ryan C. Gordon
To: SDL Development List
Sent: Wed, May 22, 2013 7:20:50 PM
Subject: Re: [SDL] Android EGL-fu

Is there any particular reason to use all EGL-related calls with JNI?
I’ve dug a little bit on the AOSP code, and realized that all java egl
related classes are merely a JNI wrapper to the proper EGL C library.
This means that when SDL is p.e. flipping buffers, it will go from C to
Java to C again.

This is a stupid question, but: is the EGL on Android any different from
the EGL for Pandora, or the Raspberry Pi, or Wayland or Mir (etc)?

(Beyond a few typedefs for display handles, etc.)

If this is basically all the same, I’d sorta like to move all of this to
one “egl” video target with a little bit of platform-specific glue code for
the different platform variations.

Which is to say, yes, in any case, it seems to me that less JNI is
better than more.

–ryan.

Ryan,

I think your assertion is correct. I found the EGL parts could be the
same and there are 2 platform specific parts. One to get the platform
display and the other for the platform window surface.

I have a small little project that basically shows this:
http://sourceforge.net/projects/eglport/
It support RAW framebuffer, SDL 1.2 (X) surface, and raspberry pi.

I was actually planning to incorporate this into SDL2 so that it would
better suit devices like pandora and rpi.

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

9

Hi guys,

I apologize for the late response on this matter. Here is the code for
C side EGL. It basically works pretty much as before, but no need for
JNI jumps at all. I implemented it mainly on SDL_androidgl.c, dont
think will have time to make as a generic EGL subset…

Let me know if it worked for you,

Cheers------
Jos? Pereira
Personal blog

On Thu, May 23, 2013 at 3:59 PM, Scott Percival wrote:

Sounds like a brilliant idea, and hopefully shouldn’t be too much work.

“Video” driver is a bit of a misnomer with SDL, as they also contain the
platform-specific hooks for input and event wrangling. For that reason you
might not want to implement EGL as a whole discrete video driver per se, but
perhaps a subset of common methods that get called by the current stack of
of video drivers.

Right now, the way it works is that the top level SDL_VideoDevice struct has
pointers to the GL context handling methods in the device driver (see
http://hg.libsdl.org/SDL/file/53df899db00b/src/video/SDL_sysvideo.h#l220 ).
In the X11 driver for instance, that means _this->GL_GetProcAddress can be
set to point at X11_GL_GetProcAddress (defined in
/src/video/x11/SDL_x11opengl.c) or X11_GLES_GetProcAddress (defined in
/src/video/x11/SDL_x11opengles.c). There’s also a generic struct pointer of
type SDL_PrivateGLESData in there, which is later defined in the video
driver (e.g. /src/vide/x11/SDL_x11opengles.h) to be a container for all of
the EGL function pointers and so forth.

The tricky part is that SDL is generally not linked to WGL/GLX/GL or
EGL/GLES at compile time, but the application most likely is. And since
there’s only one set of GL context functions in SDL, and there are cases
like X11 where you can have both GLX and EGL present on the system, they
need to be pointing at the right one for the application to work properly.
For this reason there’s an SDL_GL attribute flag SDL_GL_CONTEXT_EGL, which
hints to the video driver whether to demand an EGL display and fall over if
there isn’t one.

A good place to start might be to take /src/video/x11/SDL_x11opengl.c and
try and sieve out the platform specific bits (i.e. the LoadLibrary and
GetVisual parts).

Interestingly, Canonical have been jonesing for AMD/NVIDIA to make their
Linux desktop drivers accessible through EGL. If this happens, then we might
have to do some rework to fix all the naming and remove the assumption that
EGL implies GLES.

On 24 May 2013 01:01, Jos? Luis Pereira <@Jose_Luis_Pereira> wrote:

I will start implementing in a separate EGL driver (folder). I dont have
complete knowledge on how SDL implements the video drivers, mainly how the
macro checks are working. Any recommendations?

Also, again about Android, i would say that a OpenSLES implementation
could also be very favourable for audio, however i dont have an immediate
interest on it ATM.

Best

Jos? Pereira
Personal blog

On Thu, May 23, 2013 at 8:43 AM, Sam Lantinga wrote:

That would be great. I’d love to unify the EGL code in SDL.

Cheers!

On Thu, May 23, 2013 at 7:02 AM, Scott Smith wrote:

From: Ryan C. Gordon
To: SDL Development List
Sent: Wed, May 22, 2013 7:20:50 PM
Subject: Re: [SDL] Android EGL-fu

Is there any particular reason to use all EGL-related calls with JNI?
I’ve dug a little bit on the AOSP code, and realized that all java egl
related classes are merely a JNI wrapper to the proper EGL C library.
This means that when SDL is p.e. flipping buffers, it will go from C
to
Java to C again.

This is a stupid question, but: is the EGL on Android any different from
the EGL for Pandora, or the Raspberry Pi, or Wayland or Mir (etc)?

(Beyond a few typedefs for display handles, etc.)

If this is basically all the same, I’d sorta like to move all of this to
one “egl” video target with a little bit of platform-specific glue code for
the different platform variations.

Which is to say, yes, in any case, it seems to me that less JNI is
better than more.

–ryan.

Ryan,

I think your assertion is correct. I found the EGL parts could be the
same and there are 2 platform specific parts. One to get the platform
display and the other for the platform window surface.

I have a small little project that basically shows this:
http://sourceforge.net/projects/eglport/
It support RAW framebuffer, SDL 1.2 (X) surface, and raspberry pi.

I was actually planning to incorporate this into SDL2 so that it would
better suit devices like pandora and rpi.

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

-------------- next part --------------
A non-text attachment was scrubbed…
Name: sdl_native_egl_android.diff
Type: application/octet-stream
Size: 21618 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20130811/8b6afeb9/attachment-0001.obj