> 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
( 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 ? )
Interest mailing list