[webkit-qt] Issues with WebGL+accelerated composting on an embedded target

[david.corvoysier at orange.com]

Hi,

This is my first post on this list, so first, a brief introduction: my
Name is David Corvoysier and I have been working with various WebKit
ports (GTK, DirectFB, OWB) over a few years now, always targeting
embedded devices (typically set-top-boxes). Since the beginning of 2011,
I am solely focussed on QtWebKit, and in the process of filling the gaps
in our target-specific ports.

WebGL support is one of these gaps, and we are struggling to integrate
it properly. 
The main challenge with WebGL is that it really needs its own GL
context, but also needs to be ultimately rendered on screen using the
main graphic context, wich is typically also a GL context if you use
accelerated compositing.
My understanding of the Qt implementation is as follows:
- a QGLWidget is assigned to the WebGL canvas, whose underlying context
shares textures with the main context (this is achieved using the
special QGLWidget constructor).
- the WebGL QGLWidget is used only for its context and the canvas is
rendered offscreen in a FBO, that is mapped to a (shared) texture
- during repaints, the main context directly uses the shared texture. 
Unfortunately, this implementation doesn't work on one of our targets,
partly due to the abstraction layers we have on top of Open GL, and
partly due to some video memory limitations: all in all we cannot share
contexts between QGLWidgets.
Since the WebGL canvas is actually meant to be rendered offscreen, we
used a QGLPixelBuffer (which unlike the QGLWidget doesn't need to be
mapped on a native surface) instead of a QGLWidget, and it worked.
Now, we still have an annoying bug with our implementation, with the
WebGL context being accidentally corrupted (as if some operations
performed on the main context modified the WebGL context). We are still
investigating on this, but in the meantime we found a workaround by
calling doneCurrent after each WebGL operation: this prevents the
context corruption, but creates another problem because the depth buffer
is now flushed between operations (we haven't been able to figure out
yet if it is the normal behaviour or a platform specific bug). 
So, I have two questions for developers on this list that have been
involved with the WebGL implementation: 
- have you considered using a QGLPixelBuffer instead of a QGLWidget for
WebGL ? If yes why did you choose the latter ?
- how is context isolation guaranteed in the Qtwebkit code (ie how do we
make sure we are always working on the relevant GL context) ?
Regards
David Corvoysier
Orange Labs

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-qt/attachments/20111013/8962916f/attachment.html>