Post by Shawn Rutledge Post by Shantanu Tushar
I see that Uwe has pointed out a performance issue which can happen
because of multiple renderings due to size changes. Is that it? Or are
there other reasons behind preferring PNG icons over SVG?
I think it’s mainly that SVG rendering is slow because it’s done in
In our use case we have more of 1000 different SVGs - all of them small
and simple - the type of icons you usually have on buttons.
For those I can't confirm, having any performance problems with rendering
The problems we noticed are related to the classes in Qt/Quick core:
The caching strategy of QQuickImage, does not take into count, that
scalable graphic formats do not offer a reasonable source size and that
it doesn't make sense to render anything before the layout system has
calculated the final size for the image.
But this one is not a serious problem as long as you are aware that
QQuickImage is for raster data formats and for all sort of vector base
images better use QQuickPaintedItem.
QQuickItem and friends are not careful about avoiding geometryChanged
notifications. Binding sizes results in setting width/height in 2
separate call resulting in 2 geometryChange events.
Even worse: QQuickItem does not even have a public API where you can set
its geometry in one call. Without using the private APIs you have to set
size and position in 2 calls - always resulting in 2 geometryChanged
And here we are talking of a public C++ API - the one for the base class
of all Qt/Quick Items !
With QWidgets layout update requests are indicated by an event
( LayoutRequest ) to the parent and usually processed asynchronously.
This way several layout requests can be collected and lead to one
When binding implicitSize properties this is not the case and leads to
several updates - often irrelevant as only the last one is important.
In QSkinny I implemented a layout system, that is similar to what QWidgets
does. Layout Requests are not processed before updatePolish.
Something I have not yet fixed in our environment is, that layouting
always has to be done in top/down order. That requires sorting the items
in the to-be-polished list. I would expect to see some nice improvements
in our ( already almost non existing ) startup time.
d) Once more QQuickImage
From what I written above my conclusion is, that no class should do any
expensive operation in geometryChanged.
Finally an unrelated comment on QQuickItem::geometryChanged,
QQuickItem::itemChange and QQuickItemChangeListener:
why do those APIs exist at all ?
Sending events is a well established mechanism that exists since ever and
event filtering is public, available and more powerful ( swallow events )
than those listeners.