> - have you considered using a QGLPixelBuffer instead of a QGLWidget for WebGL ? If yes why did you choose the latter ? >I think QGLWidget was a bit more straightforward - you just share the context with the parent and use an FBO. For most use cases this does not cause drawing issues.
Actually, we are still using the WebGL FBO, but the context is created by a QGLPixelBuffer and not a QGLWidget: it requires only a small change at initialization, and we don't need to allocate another eglsurface (which was what we couldn't do on our target). >It's probably possible to implement this with a pixel buffer as well - though how would that work in a cross process environment? >Right now my thoughts for WebKit2 are to either use EGL images (with Mesa for desktop) or streamline GL commands to the UI process. Since as I said we still use a FBO, there is no difference in implementation with the QGLWidget approach. That said, I haven't looked much into WebKit2, but my understanding is that the rendering and composition (UI) processes are separated. I assume that layers are prepared in the rendering processes, and at some point you pass an 'image' and a geometric transformation to the composition process (very much like in the texture mapper). The main question is how you make your intermediate rendering available to the composition process: you can use shared memory if you have a system buffer, but if your rendering has been done by the gpu, you may want to avoid the soft copy: this can be achieved more easily on the desktop (Mesa/DRI) than on embedded targets, where you will probably have to rely on proprietary mechanisms. The other option is as you said to streamline GL commands to the UI process. This is probably a bit more complicated (but chrome has an implementation for that already if I remember well how their own gpu process works), and you gain the ability to further isolate the rendering processes: imagine for instance that you want to restrict the gpu access to the UI process only for security reasons. _______________________________________________ webkit-qt mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-qt
