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

[Uwe Rathmann]

On Thu, 15 Mar 2018 14:26:41 +0000, Shawn Rutledge wrote:

>> 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
> software,  ...

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 
them.

The problems we noticed are related to the classes in Qt/Quick core:

a) QQuickImage

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.

b) QQuickItem

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 
notifications.

And here we are talking of a public C++ API - the one for the base class 
of all Qt/Quick Items !

c) Layouting

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 
calculation only.

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.

ciao,
Uwe