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. Uwe _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest