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