Hi,
On Tue, Dec 30, 2008 at 3:52 PM, camako <cemil_azizo...@yahoo.com> wrote: > > > I've seen the messages about Android not being ready for h/w > accelerated OpenGL|ES, etc.. We have an existing OpenGL|ES driver > (with an EGL implementation that supports full screen apps only) which > we've enabled Android's surfaceflinger to use. But we used a hack and > I'd like to know whether experts think we'd get into trouble in the > future for doing what we did. > > What we did is basically create our opengles library under a new name > (e.g., libMyOpenGLES_CM.so) and had the Surfaceflinger link to it > rather than the software version. We had to resort to some other > hacks, like eliminate some android specific extesions, etc that we > don't have in our version. Obviously, this only works for the > surfaceflinger app since it's a full screen app using the whole > framebuffer chain owned by the FBDev. We also changed some flinger > code to use our NativeWindowType which is not the same as the one > provided in Android. As long as your changes are limited to SurfaceFlinger, it's not all that bad. I'm not saying it's the right way to do it, but since there is no "right way" at the moment, it'll do. That being said, you *shouldn't* have to link against your own OpenGL library. The reason why you have to do this is because you don't use Android's NativeWindow type (naming your lib libhgl.so should be enough). You really need to fix that, that's par of the "contract" (note that NativeWindowType will change soon). > Next we will be enabling, non-flinger apps (i.e. apps that do not > "own" the FBDev buffers) . Again we will be using our own existing > NativeWindowType which supports this, and not the > EGLNativeWindowSurface type that android uses (and yes, we will have > to change some android code, like opengles JNI code etc...I know it's > bad). You shouldn't have to touch the JNI code, which part are you thinking of changing? > Apart from the buffer copy from our driver's render target to the apps > surface on every eglswapbuffers, what other problems (as I know there > must be) do you see with this? It should work. Of course, you'll have a performance penalty due to the extra copy (and since SF makes a copy of the surface to the framebuffer, that's in fact 2 copies per frame, instead of one -- in the future, we're planing to allow SF to handle full screen GL apps with zero copy and possibly windowed GL apps with zero copy as well). I think the biggest problem you'll run into other than the extra copy is that you won't take advantage of the improvements / bug fixes, etc... of the system, since essentially your GL implementation runs "on the side". Another problem you WILL run into, is when we release an NDK (native apps dev kit) and when we allow it to use OpenGL. What will happen then, is that these apps will link against the wrong library. All that being said, your approach is not too bad (except for the extra copy :)), and I don't understand why you couldn't make it work without any modification to the system. You'll just need a shim around eglCreateWindowSurface() and eglSwapBuffers() that looks at the passed NativeWindowType, figures out if it's the framebuffer or a surfaceflinger window and creates a surface with your "internal NativeWindowType", then on the eglSwapBuffers() side, depending on the case, you'll do the extra copy or not. If you do not have the sources to your GL implementation, you probably can use some linker tricks to "trap" the calls to the interesting functions. What I'm suggesting is that you do all the "trickery" inside your libhgl.so, instead of modifying the system. I'm curious to know how your NativeWindowType is defined? Mathias --~--~---------~--~----~------------~-------~--~----~ unsubscribe: android-porting+unsubscr...@googlegroups.com website: http://groups.google.com/group/android-porting -~----------~----~----~----~------~----~------~--~---
