[Development] Mixing OpenGL and Raster

[Uwe Rathmann]

On Tue, 16 Oct 2012 09:18:39 +0200, Samuel Rødal wrote:

> Right, it's possible to do native ES 1.x rendering with Qt 5, but at the
> moment there's no ES 1.x capable paint engine, and QML 2 requires ES 2.
> It would be possible to write a new ES 1.x paint engine (or port the one
> from 4.8) if needed.

As all what we have is the raster paint engine our code uses QPainter 
today - that also works with QGLWidget on the PC pretty well. As we don't 
want to reimplement the whole thing in "native" OpenGL, a working ES 1.x 
paint engine is indeed our favored solution. For us it would be enough to 
see it fixed in Qt 4.8 as we already have trillions of lines using 
QWidgets and I can only imagine using QML for new applications on a 
different hardware.

I remember that I stopped at a stage, where I had fixed the stacking 
problems ( it was all in one file that explicitly ordered the OpenGL 
surfaces on top for whatever reason ). The next step I had in mind was to 
introduce a buffering ( in video ram ), to imitate the behavior of the 
raster surfaces to avoid having to fix all the situations, where Qt tries 
to restore the contents of the screen from it.

But even with a hacked OpenGL implementation ( ignoring certain 
situations showing a black content ) I noticed that a lot of CPU was lost 
in the tesselation that was done in software inside the OpenGL paint 
engine. Unfortunately it also produced so many polygons, that sending 
them to the graphic chip was another bottleneck on our system. In the end 
we had so many polygons, that in a worst case scenario it was worse than 
what we had with raster.
 
On Tue, 16 Oct 2012 09:01:17 +0000, Sorvig Morten wrote:

> One possible solution I've been considering is client side compositing:
> Create one OpenGL surface for each top-level QWindow, then render child
> QWindow raster content into a texture and OpenGL content into a FBO.
> 
> Granted this moves you even further away from native x11 painting, but
> do you think it could be a feasible solution on the hardware you are
> working with?

We are using QWS ( we don't even have X11 for the Carmine chip ) so this 
is no problem - but by QWindow you mean Qt5 ?

Uwe