> On 7 Mar 2018, at 09:08, Uwe Rathmann <uwe.rathm...@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? _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest