Hello to all, I have been tracking the development and extension of OSG's support for Android as I want to use the library and its overwhelming capabilities for a personal project in the field of Geodesics and CAD. I an happy to see that there are already people like Jorge Ciges and Rafael Gaitan (and probably many more) that are contributing and easing the integration of OSG to an Android app. I have decided to devote some time to investigate the possibility of implementing an Android-specific, GraphicsWindow class and maybe a osgViewer::Viewer derived class that would allow multithreaded rendering and some other goodies to be possible. I decided to share my insights with you and ask some questions about the feasibility of such a feature, so here comes the background.
The current support code is centered around Android's Java API GLSurfaceView which builds and scraps EGL contexts, makes GL calls from a separate thread and manages window buffer lifecycle. While this will work, it implies the use of a mock implementation of GraphicsWindow in osg and gives little control over threading. There is already an publicly exposed API for GL context managent in Android's NDK, with the only problem that Android has a system-wide windowing manager with no API for requesting windows that can be used for creating EGL Surfaces. Instead, there are several Java classes, (namely Surface and SurfaceTexture) that wrap around a window handle that can be used to create an EGLSurface, more can be read herehttps <https://source.android.com/devices/graphics/architecture.html>:// <https://source.android.com/devices/graphics/architecture.html> source.android.com <https://source.android.com/devices/graphics/architecture.html> /devices/graphics/ <https://source.android.com/devices/graphics/architecture.html> architecture.html <https://source.android.com/devices/graphics/architecture.html> . The problems come from the fact that instances of these objects are received as arguments in callbacks, defining their lifecycle. So my questions are: 1. Is it possible to use a semi-valid GraphicsWindow to initialize an osgViewer::ViewerBase derived class? By semi valid I mean providing a GraphicsContext object having a valid EGLContext with no EglSurface to make current until one is available to be created. 2. Is there any existing functionality to tell a GraphicsThread to release a lost context/bad eglsurface and wait until its signalled that a valid context is obtained again? Is adding a custom Operation to its OperationQueue a solution? 3. How to handle a scenario when a EglSurface is no longer valid (when I recejve a callback that the window buffer is about to get destroyed)? 4. After an EGL context is lost, usually after a device screen lock, what are the correct steps to tell osg to stop using the old context and refresh any context-related objects after a new context gets attached to a viewer? 5. When in some of the multithreaded modes of a Viewer, how can existing threads just get paused after completing any pending operations instead of getting scrapped with Viewer::stopThreading()? How can the existing Barrier be used to accomplish this, if possible of course? 6. Can you point me to a good example that explains the steps needed to properly initialize and run a Viewer? I hope I'm not asking too much and that my questions won't be too specific. I have already made some JNI wrappers for handing the lifecycle of window buffers, I managed to set a proper Android project with NDK support, successfully got through the compilation process of OSG and I have helper classes for C++ EGL context creation. Any answers would be great and will help me a lot in my efforts. Thank you. Regards, Georgi Neykov
_______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
