Hi Georgi, I'm going to try answer what I can, but probably there are some more complex questions that Robert could answer much better.
2014-12-28 9:19 GMT+01:00 Georgi Neykov <[email protected]>: > 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. > Yes, using osg::GraphicsContext::Traits and creating your own GraphicsWindowAndroid implementation. I'm pretty sure there's a GraphicsWindowEGL implementation already in OSG, but the problem for Android probably is passing down the Events, from the native part. Take a look at the samples I write down later. > 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? > Not sure what do you mean here, but the functions for doing flush and discard can be found in include/osg/GLObjects: /** Flush all deleted OpenGL objects within the specified availableTime. * Note, must be called from a thread which has current the graphics context associated with contextID. */ extern OSG_EXPORT void flushDeletedGLObjects(unsigned int contextID, double currentTime, double& availableTime); /** Flush all deleted OpenGL objects. * Note, must be called from a thread which has current the graphics context associated with contextID. */ extern OSG_EXPORT void flushAllDeletedGLObjects(unsigned int contextID); /** Discard all deleted OpenGL objects. * Note, unlike flushAllDeletedObjectObjects discard does not * do any OpenGL calls so can be called from any thread, but as a consequence it * also doesn't remove the associated OpenGL resource so discard should only be * called when the associated graphics context is being/has been closed. */ extern OSG_EXPORT void discardAllDeletedGLObjects(unsigned int contextID); 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)? > Probably you'll need to deal with that in your GraphicsWindow Implementation. 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? > OSG will re-compile automatically the objects of the scene for the new context, the problem will be for those objects that are discarded and you have lost the info for reloading it (like textures where you have set the "UnrefAfterApply", but I think it won't be much problems about that. > 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? > I don't understand the purpose of this :) > 6. Can you point me to a good example that explains the steps needed to > properly initialize and run a Viewer? > Yeah, take a look at this examples: osgcamera (creates single/multiple cameras using traits and a graphics context) osgviewerQt (this examples uses a GraphicsWindowQt implementation to integrate properly with Qt) I think a similar approach should be possible for Android > 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. > I think is doable, we tried to do it some time ago, but we discovered that native support at that moment was not enough, probably now is possible and indeed is possible to capture all the events in the native GraphicsWindow implementation and start the context using EGL. Regards and good luck! Rafa. Regards, > Georgi Neykov > > _______________________________________________ > osg-users mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > -- Rafael Gaitán Linares CTO at Mirage Technologies S.L - http://www.mirage-tech.com
_______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
