[Development] QT_XCB_NATIVE_PAINTING makes worse that without of it

[Uwe Rathmann]

Ön Fri, 22 Mar 2019 17:06:32 +0100, Allan Sandfeld Jensen wrote:

> Sounds like XCB isn't as well optimized as Qt is

Nice joke - but only when X11 falls back on some software emulation it
might be the case, that the Qt implementation is better than that one.

> Note though, that there are number of techniques to make the native 
> painting faster, such as always using qpixmap so the images stays 
> buffered on the server side.

Unfortunately after removing the X11 paint engine with Qt5 the Qt
development started to rely on the fact, that QPixmap::toImage() is a
cheap operation - what is not true anymore since Qt 5.10 and
QT_XCB_NATIVE_PAINTING.

F.e. in qquickpixmapcache.cpp you find code like this for creating
textures for QQmlImageProviderBase::Pixmap:

     QQuickTextureFactory::textureFactoryForImage( pixmap.toImage() ) );

Here Qt/Quick is affected, but I have seen stuff like this in the Qt/
Charts module and there are probably more ...

> You might be able to massage your program to be faster with native 
> painting, but the whole reason for switching to Qt side painting was 
> that for the average application developer Qt side was faster.

Not sure what "average" means, but when talking about vector graphics
this nothing but wrong. I had posted statistics some years ago showing
how much slower software rendering for the type of use case you have
with Qwt:

my test was about creating the same QImage using QPainter::drawPolyline
in 3 ways:

- Drawing to a QImage ( = raster paint engine )
- Drawing to a QPixmap + copying it out to a QImage ( X11 paint engine )
- Drawing to an FBO + copying it out to a QImage ( OpenGL paint engine )

I don't have the numbers anymore, but IIRC on my box OpenGL/X11 were >
10 times faster than what the raster paint engine does - even if the
numbers include an irrelevant QPixmap -> QImage operation for OpenGL/X11
and the time for the QImage upload for the raster paint engine path is
missing.

Uwe