[Interest] How to render small Images decently on non retina displays with QtQuick?

[Uwe Rathmann]

Hi Shawn,

> It should also be considered a bug IMO.

The only obvious part of the whole disaster that IMO qualifies as a "bug" 
is the fact, that binding a size ends up in 2 calls - but AFAIK this is 
not specific to QQuickImage.

Maybe one could say, that QQuickImage shouldn't do any updates before 
updatePolish, but this would be the opposite of the overall "as soon as 
much as possible" caching strategy implemented in Qt/Quick.

I once derived a small class from QQuickImage ( https://github.com/uwerat/
qskinny/blob/master/playground/images/Image.h ), to avoid some of these 
issues, but I never used it as we later decided to go with writing our 
own code for displaying images.

This code uses a class that is called QskGraphic, what in the end is a 
record/replay paint device - similar to QPicture, but tailored for 
scalable vector graphics.

This way we can precompile our SVGs at build time into QPainter commands 
and store them into as something we call a qvg file. As we have small 
iconic graphics only we can load those files from disk in updatePolish 
and replay the commands in updatePaintNode without needing any cache at 
all.

( If you are interested: the qvgviewer example in qskinny uses it. )

Maybe a side node: IIRC creating a QImage and translating it into a FBO 
seems to be faster - when having simple icons - than creating the FBO 
directly. Looks like the tesselation done inside the OpenGL paint engine 
is as expensive as what the raster paint engine has to do for pixeling 
down the RGB values.

( But this is something I noticed 2 year ago and might have changed in 
the meantime ? )

Uwe