SVG vs PNG

In this article we want to discuss the advantages and disadvantages of SVG and PNG image formats in the context of developing applications on embedded Linux using Qt. The main goal of this project is to evaluate the technical aspects but we will also talk about how the formats influence the overall development process. General Considerations Often in developement requirements change after the designer finished creating assets and an icon may be required to be displayed in another color or size. Sure, we can scale down a PNG, but we cannot increase the resolution. Changing the color also raises challenges as antialiasing usually creates a whole palette of colors between the fill and background (often transparent) color. Recoloring a PNG is not as simple as changine a hex value but requires more complex operations to transition the whole palette. This is where SVGs can shine. We can render the image in an arbitrary size and changing the color is as easy as changing the fill=““ attribute of the xml node. We can also cleanly combine different icons or seperate one into many in perfect quality. So what is the downside of SVGs? Well, one could argue they less „portable“ than a PNG. A PNG is just a grid of Pixels, compressed using a small set of algorithms and rules. SVGs however allow us to define an image using simple geometric shapes, similar to rendering APIs like a html/js canvas. But not just forms, also gradients or shader effects such as blur or drop shadows. Combinations of shapes: Masks, intersections, differences… The SVG specification has changed several times and was expanded to allow more features. Software, on the other hand, which converts these clear-text drawing instructions into an actual pixmap might not support all of these features. The same SVG file might look completely different in your browser than it does in a Qt application for example. While Chrome pretty much supports SVG 2, Firefox does not yet fully support SVG 1 (source: https://caniuse.com/?search=svg%201), but both will display most SVGs correctly. When it comes to Qt we are even further behind. As Matthias Rauter recently explained in a a blog post, up until Qt 6.7 Qt’s SVG Renderer only supported the subset SVG Tiny 1.2. In this slimmed down version many features, such as effects and masks are not available. With Qt 6.7 Matthias has added some of these features. Does this make SVG completely unusable? No. We yet to find one of the 3000+ Google Material Icons which does not fall under SVG Tiny 1.2, and many SVGs using masks or other operations can be rewritten with reasonable effort. With this, not quite so short introduction, we are at the actual starting point for this experiment. How do SVGs hold up in practice when it comes to computational complexity? Can SVGs keep up with PNGs or even surpass them in certain situations? This is the question we want to answer with our benchmark. Benchmark For this benchmark we wanted to see if SVGs can keep up with PNGs on the edge or maybe even outperform them in some aspects. The idea for our benchmark is as follows:

• We get a large set of SVGs
• We use a terminal SVG-renderer to export them to PNGs in different resolutions
• We put all those images into a Qt Resource file and load all images for each size, once as svg, once as png
• During the tests we monitor CPU and RAM usage

Timing

• We are using QtQuick to set up a window
• Sampler finds all images of given type (svg, png24, png48, …)
• In Main.qml we setup a Loader and request a batch of image urls from the sampler to show as many images as fit on the screen
• We use a Repeater to instantiate Image s for each image in the batch and use a GridLayout to position them
• We measure the time between the loader retrieving a batch of urls and Loader.status changing to Loader.Ready

Results Toradex i.MX8M Plus Verdin Board with tdxwayland Yocto (Qt 5.15) Ginzinger i.MX8M Plus with GELin (Qt 5.15) Lenovo Thinkpad P53 with Ubuntu 22.04 (Qt 5.15) We can see that the PNGs render slightly faster (up to 1ms per sample) for small icons (24, 48 pixels), but from about 128 pixels onwards the SVG starts to become faster. In my opinion this behavior can be explained by three main reasons:

• SVG reading & parsing stays constant no matter the render size
• PNGs become larger with the amount of pixels (see below), 24px samples are even smaller than svgs on average
• SVGs use similar elements as high-performance rendering API, drawing rectangles and other geometrical shapes. These can be parallelized by the GPU whereas decompression (DEFLATE is used in PNGs) might have to take place in the CPU and cannot be multi threaded the same way.

Additionally to the measurement, a test with these two image formats was done to find out, whether subjective differences in the performance of the user interface can be found. These impressions are summarized in the below video.