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 _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest