SVG all the things, now!

It started with "the icons look blurry" from a friend, and I was puzzled, as the icons look fine. We went to a lot of bother to make nice clean PNG images for the icons on the FireBrick config editor.

It turned in to a project taking me at least 4 days so far... I'll never be an artist!

Icons look blurry

Why did they look blurry? Well, the answer is simple - high resolution monitors! I have a 5k Mac, as does my friend, and on such a high resolution screen you just get used to the fact that all pixel graphics look blurry. To be fair, a photograph does not, but an icon, where things should have sharp edges, do not look right. I blogged an example of this recently. Here, I try to go in to a lot more detail.

Here are examples - the first is the original PNG, scaled up showing the square pixels. The second is the blurry version, cubic scaled up as would happen on a monitor that has much higher resolution. The third is a rasterised version of the SVG we now use.



The pixel version was good, it was the best you could do for the pixels available. The scaled version is pretty good, but is indeed blurry. What happens is the sharp transitions on the pixel version are softened. This makes a lot of sense with a photograph as it stops you seeing the harsh edges and makes for smooth transitions in colour.

The SVG though is perfect at any scale, and that is because it is vector based (the V in SVG). It involves lines, and shapes created using points and straight line segments and curves between those points. This is something you could draw at any size. A diagonal line is diagonal and not a jagged series of pixels making a "staircase" effect. Now, ultimately, this ends up on a screen that has pixels, but that conversion to pixels can happen at the last moment for the final resolution of the screen. If you actually had a vector output device, like a pen plotter, it could actually draw the vectors with no pixels.

That is what makes SVG very different. Vector graphics verses raster graphics. The age old issue. But now with computer screens, and even mobile phones, being such high resolution, we need things to be designed from the start as vector graphics. With the possible exception of Minecraft.

Changing this on the FireBrick was simple because we actually have SVG masters for all the icons. Our build process made PNGs from them. On a low level screen all three of those images would look the same in their original size. When all we had were screens that showed images 1px to 1px scale, it looked as perfect as it could.

Sol, given we had SVG, why did we use pixel based PNG. The reason is simple - when FireBrick started browsers did not support SVG, or need SVG as monitors were not so high resolution. Indeed, even javascript was not something on which one could rely. Finally we are at the stage where SVG is pretty much a given, as is javascript. So now we can use those nice vector originals we have had all along.

I can't just leave it alone, can I?

Basically, that was far too easy. It took my minutes as we had the SVG masters of the icons and could just use them.

So this led to my changing the CQM graphs... These are the loss/latency graphs we use for monitoring links, and A&A use for all broadband customers...

Existing graphs were pixel based in the same way, and when viewed on a same resolution screen they look good. They try to present a lot of data, and have options to only show some of the information on the graph, and to adjust scales, and colours and so on. Indeed, the A&A control pages are rather colour-blind friendly by allowing control options for customers to see the graphs in different ways or as multiple graphs even, at least for the "live" graphs.

This is what they look like as a PNG:-



Coverting this to SVG was not so simple - I had to make the raw SVG from the data. I managed to make a lot of common functions to the PNG generation, e.g. text placement and colours, but even that needed work as it made for inefficient SVG. To be honest, it would have been nicer to start from scratch, but I wanted to maintain the layout, at least for now.

A big change was the tx/rx rates which could now sensibly be lines, and not points. SVG makes that very simple.

I did this in all in one day, but have now spent three more days tinkering. It is like a piece of art - I am either fine tuning what you see - moving something half a pixel over, or I am fine tuning the SVG, making it more compact. It is potentially never ending, which is frustrating. I would never make a good artist a I would never finish any piece of work. I even ended up making some generic SVG path optimisation logic to make the paths shorter textually by use of relative points, the "h" and "v" functions, and even not making two segments that could be one segment in a line.

Now, to show you the SVG, but blogspot does not allow me to - WTF?
Fortunately, hosting it and editing the HTML works... So here is the same graph as an SVG:-



This is not the latest version, I will have that on LNSs later this week. I have, for example, moved it 0.5 pixels to the right as the line on the left is one pixel wide at 0 pixels so only shows half a pixel wide! I have fin tuned the size and placement of text (most of which you don't see on this example as it is customer line specific), and optimised a lot of the SVG for things like the "hour" numbers, and so on. This is from at least a day ago... So much has happened since then.

There is one more place...

We present a QR code for Two Factor Authentication TOTP set up on the FireBrick web page. This was generated as a QR code as a simple bit map and then made in to a PNG.

The logic for this already had to make it bigger than it should be, with each QR code pixel being a 4x4 image pixel as simply scaling up in the browser made it "blurry"...

So for the SVG I had to create code to "trace" around the pixels, making an outline for the black parts. Rather than simply making it lots of small squares that butt up against each other I decided to make it actually "trace" the outline of multiple black pixels. It has to trace the "inside" white parts the other way (e.g. counter clockwise), and so on. One thing I was unsure of was whether to follow a "diagonally" joined pixel as part of the same outline - it turned out to save a few bytes as it meant longer paths of "h" and "v" relative points rather than "M" absolutely points for each small part, but it was literally like a dozen characters saved. Even so, the result has no nasty "joins" between adjacent pixels which I have seem break things when scaled up.

The result looks identical to the PNG, e.g. (screenshot):-

SVG is the future of all icons on the web!

The fact we have so many high resolution devices, and scalable screens (e.g. phones) means we need to abandon use of pixel based icons on web pages pretty much. It looks "blurry" normally and just bad when scaled up.

This has turned in to quite a long and fun project, and something we really need to extend to more places, the main web site, control pages and much more.

For now the challenge over the next few weeks is simply switching the A&A control pages to show the new SVG graphs as we update the LNSs. They are already proving very popular. As we have so many LNSs now, this will take a couple of weeks, sorry.