[Development] Proposal: Make QPen non-cosmetic by default

[Samuel Rødal]

On 10/15/2012 09:36 PM, Uwe Rathmann wrote:
> On Mon, 15 Oct 2012 09:58:20 +0200, Samuel Rødal wrote:
>
>> Could you elaborate on what you mean regarding the implementation of the
>> subsurfaces concept?
>
> This is an experience from a project I'm working on:
> http://www.youtube.com/watch?v=8Zgnv-qz744
>
> I spend some time on trying to embed an OpenGL widget into an application
> using Qt/Embedded. These attempts were made with Qt 4.6 and Qt 4.7 - so
> please excuse me when everything written below is obsolete for the
> versions of Qt you are interested in.
>
> When you have a look at the configure script for Qt 4.8 you will find a
> compiler flag "Q_BACKINGSTORE_SUBSURFACES" that gets enabled as soon as
> you enable OpenGL. Its effect is that you can have surfaces with a
> different paint engine inside of another surface - what you need when you
> have an OpenGL widget embedded in a regular top level window.
>
> With Qt 4.6 I noticed that the translation of the widget content to
> screen coordinates was broken ( wrong regions were updated ) only when
> enabling Q_BACKINGSTORE_SUBSURFACES - even without using any OpenGL
> widget. I spent some time on fixing these bugs ( I remember reading
> comments in the Qt code, showing that the developer was aware of the
> problems ) and provided some patches that made it into Qt 4.7. ( You
> might find the history in the Qt bug tracking system or maybe together
> with the applied patches )

Right, I'm not too familiar with the Q_BACKINGSTORE_SUBSURFACES code 
paths, but I seem to recall that it was in an experimental state. The 
official position was that QGraphicsView is the best way of mixing 
OpenGL and raster content (without having multiple overlapping native 
windows).

The native window code in Qt is a bit messy, due to the "native" widget 
legacy where every single widget was native. That of course was changed 
with the introduction of alien widgets, but there are still annoying 
issues such that if you make a widget native (or insert a QGLWidget 
inside an existing widget hierarchy) then all parents and siblings of 
that widget also (unnecessarily) become native.

> But when really trying to work with OpenGL I came across many other
> problems. F.e. I remember that OpenGL surfaces are always sorted on top
> of regular surfaces ignoring the window stack. I found several situations
> where the framework tries to restore the screen from some cache that
> doesn't exist for a OpenGL surface ...

I guess this is QWS specific? OpenGL support in QWS was always so-so 
from what I've heard (was never really involved in that bit).

> Unfortunately at that time the usual answer from the Qt support was that
> QPA will be the future and nobody wants to touch QWS anymore. QPA with Qt
> 4.8 was then declared ( on the mailing list ) as "not yet worth to be
> documented" ( please excuse me, when I don't have the words exactly in
> memory ) and with Qt 5.0 OpenGL/ES 1.x ( this is all we have for our
> different boards ) is not supported any longer.

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.

--
Samuel