This is good to know, I personally never fall in a such case, but I will
keep that in a corner of my head.
2018-03-07 9:08 GMT+01:00 Uwe Rathmann <uwe.rathm...@tigertal.de>:
> 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.
> Interest mailing list
Interest mailing list