Resolution independence & hardware accelerated vector graphics

Working with clever people is great, but sometimes it comes back to bite you... This post is going to describe a great new feature in Qt and why we're not going to implement it. :-)

Over the last few months I've been toying with the idea of starting a new research project to develop a binary vector graphics format, qvg. Why? Well, svg's great and all, but it does too much: You can embed animations, text, has a DOM tree, all sorts of things. It's also a plain text format (xml) so slow to initially read & parse. QVG would be our own binary file format to describe vector graphics with paint engine specific sections. You could take an SVG (which only uses a subset of the standard) and “compile” it to a qvg. During the complication, off-line processing can be done. E.g. Obscured regions of geometry could be clipped, vector paths could be triangulated, gradient textures could be generated, etc. etc. There's loads of optimisations we could do to "compile" svg into a binary format.

So, why would we want a compiled svg? Because it's faster to load and render than svg! So the question actually becomes, why do we want svg? Theming, that's why! Qt provides applications with re-usable UI controls, things like buttons, scrollbars, tick boxes, etc. C++ programmers can write applications using those controls and graphic designers can create themes for them. The idea would be for those graphic designers to draw their super sexy looking scroll bar, export it as SVG and then compile it to QVG, where it would be rendered very quickly by one of Qt's paint engines.

Having patted myself on the back for coming up with a great idea, I started talking to people about it. Most people in the graphics team seemed to like it and are already developing something a little similar. I then figured it would be a good idea to talk it over with our theming expert, Jens. "What's wrong with pixmaps?" was essentially his first reaction. Well, good question. The problem with pixmaps is that they're not resolution independent. If I want a theme to work equally well on both my 96 dpi TV and on my 320 dpi smart phone, pixmaps aren't going to work. The scrollbar will be too small on the smart phone but take up half of the TV (unless you've got a fancy HD one). The only option would be to scale the pixmap, but that generally looks horrible.

We talked about it and compared pixmaps to vector graphics and the advantages of each. I honestly thought that qvg would solve all the problems with svg (I.e. it's speed). But then Jens delivered the mortal blow to my argument: If UI elements are themed as vector graphics, the graphic designer can influence rendering speed. Think about it: If the scroll bar button is a single square and triangle, it will render very very quickly. However, if it's a vector path with a pen and conical gradient, it's going to be much slower to render. We'd get into the silly situation where people change the theme to get better rendering performance.

So, the answer is to use the best of both worlds: Supply themes as resolution independent SVGs, but cache them as a pixmap (in the correct resolution) and just render that. You get the flexibility of vector graphics but the speed of pixmaps. Of course this isn't a new idea either – Both GNOME and KDE already do this.