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

[Shawn Rutledge]

> On 7 Mar 2018, at 09:08, Uwe Rathmann <Uwe.Rathmann at tigertal.de> wrote:
> 
> On Tue, 06 Mar 2018 16:55:23 +0000, Nuno Santos wrote:
> 
>> I just had to add it to resources and pass it to the image element.
> 
> Using Image works, but its implementation is far from being optimal in 
> combination with SVGs. For small applications with only few SVGs this 
> might be no problem, but when having many of them it is often a serious 
> performance killer for the startup time.
> 
> In short: the overall strategy of Qt/Quick is to cache as much and as 
> early as possible - in case of the Image/SVG too early:
> 
> it loads and renders the SVG according to its sourceSize as soon as it 
> sees the URL. But in case of scalable graphic formats the sourceSize 
> ( usually the viewBox of the SVG ) does only provide the aspect ratio, 
> but not the size that is needed to be rendered.
> 
> This is usually solved by binding the sourceSize to the size being 
> calculated from the layout code, but ...
> 
> When having a layout system that relies on binding the implicit sizes the 
> geometry of each item changes several times until it reaches its final 
> size - each time re-rendering the SVG.
> 
> ( In fact it gets re-rendered twice each time, because binding a size 
> leads to separate updates of width and height )
> 
> I remember an application, where SVGs have been re-rendered more than 10 
> times before they had their final size. This application had more than 
> 1000 SVGs and - even if only few of them were visible in the beginning 
> the caching strategy of Qt/QQuickImage lead to more than 10000 image re-
> rendering operations.
> 
> So I would recommend for every application having many SVGs: never ever 
> use Image and always go with QQuickPaintedItem.

It should also be considered a bug IMO.  Do you know of any reported bugs about this?