Hacker News Reader

Comment by oofabz | Hacker News Reader

A vector format is insufficient to make an image look good at all resolutions. Without hinting, lines are not aligned to pixels, making them blurry.

We have solved this problem with fonts, but it is extremely complex, both for the artist and for the rendering code.

View on HN

Optimizing for hinting has been rendered pointless by the fact that people zoom around on mobile devices.

You can no longer expect bitmap pixels to map to device pixels in any reasonable way. (Heck, just turn your desktop browser zoom to 90% or 110%.)

There was a time for hinting, but it's long gone.

Not to say, if you (easily on such devices) zoom to max zoom on a hi-res display, the resulting image is 8times zoomed in comparison to normal desktop PC image. And for same quality (sharpness), you wouldn't only need 8times larger PNG for this, but 8x8=64times larger PNG.

PNGs will not scale with pixel count, especially for rendered vector art. The memory footprint will scale though.

I meant, if you need perfect sharpness for the zoomed image, you need to supply bigger PNGs, otherwise they're blurred

Tloewald is saying that if you save vector art at an 8x scale PNG, it will not be 64 times larger. Most pixels in vector art are in contiguous blocks of either solid colors or linear gradients. After prefiltering, both cases reduce to a single value followed by a run of zeroes, which DEFLATE will compress extremely well.

So the only size increase really comes from the edges. In practice, this means that an 8x size increase will often only increase the file size by around 10x.

Modded down for making accurate statements? Awesome.

As an experiment, I took two vector art files I had, one very simple (a flat icon design) and the other very complex (a texture for a 3d model with lots of drop shadows and non-linear gradients).

The SVGs in question were 6kB and 568kB in size, respectively.

At 25% size (around 256x256px) the PNGs were 13kB and 30kB respectively.

At 100% size (around 1024x1024px) they were 60kB and 266kB respectively.

I scaled the complex image to 200% (2048x2048) just out of curiosity, and it became 841kB, roughly 28x the size of the smallest, which uses 1/64 as many pixels. It is interesting that the complex image seems to approach size growing with area at the high end of resolution. Of course, this is a sample of 2.

I don't understand what exactly zooming has to do with hinting. Fonts use hinting to great effect, and they're specifically designed to be displayed at different sizes and resolutions.

Hinting makes all vector drawings (including fonts) look better; but zooming means that bitmaps don't have an advantage, since a PNG will be no better than an unhinted SVG.

That's not true at all. Firstly, any PNG would have a limited resolution, requiring massive file sizes to be indistinguishable from an SVG. Secondly, browsers don't scale bitmaps with perfectly alias-free filtering, which means you get artifacts when scaling down and blurryness when scaling up.

Except we have the reverse problem with raster images now that we have devices with vastly different DPI. An iPad 3 has like 4X the DPI of a 30" screen. If you want them to be displayed at a reasonable size on both devices? You've got a problem.

If we start seeing 4K screens, worrying about those blurry anti-aliasing lines is going to seem absurd.

So the question is whether to (1) make the experience worse for people with high-DPI devices, (2) make the experience worse for everyone, or (3) make one bitmap for one market and another, larger bitmap for the other market. I'd imagine that most web projects have a vast majority of users on "normal" DPIs, so the best options would be (2) or (3).

I have several screens in this DPI range. Actually, at 4k 30", your phone is probably in this range.

Use your phone to contrast AA to non-AA. The difference is still pretty enormous in my opinion.

A generation ago, paper had the kind of resolution that screens do now, and all the problems mentioned in this thread came up when books were printed. This made them problems for Donald Knuth. He tackled them with his usual genius, and the result, MetaFont, has been free software ever since. I've always thought a time would come to embed it in web browsers; it sounds like now might be that time.

This is true, but it's still much better than pixelated blur or aliasing. Also, most of the time you have the same problem when authoring a bitmap with vector tools too, unless you very carefully target a specific output resolution. If you really need pixel precision you can always use bitmaps, but vector is perfectly fine in many/most cases.

I wonder though - would it be possible to apply hinting to svg with javascript?

Retina displays are removing the need to worry about this. When pixels are invisible, hinting problems are invisible too.

They don't, hinting is also about removing details which you can't do in SVG.

When people provide icons in many physical sizes, the icons generally aren't mere scaling up and down, because even if you can hint so the lines themselves don't blur the details will get so small the whole icon becomes a mess. Apple even has a note on this in their HIG:

> If an icon’s content or shape is overly complex, the details can become confusing and may appear blurry at smaller sizes.

note that this is not about logical size and retina displays, it's about physical size and the viewer's eye's power of resolution.

Well, you also can't do that in PNG format.

Plus, couldn't you have multiple layers of SVG, and have the javascript respond by hiding/showing detail layers? SVG is more javascript-friendly than PNG so there's opportunity to have one SVG that gets tweaked by your js instead of multiple raster files.

SVG is more javascript-friendly than PNG

That sounds more like a problem than a solution to me.

Correct. But PNG works and is widely deployed today. Considering SVG fails at one of the primary use cases where it could have an edge over PNG, it's no surprise few care for it.

This could be done programatically. Most vector map software manages it, SVG should adopt it.

Great, so now we've got an image format which does not work by default.

You can create an SVG where certain elements are hidden when rendered below a particular size using embedded JavaScript. It would be a pain in the ass because it would have to be done by hand, but you could do it. It's a problem with the tools we use to create SVGs, not the capabilities of the format.

Hmm, could it be done via CSS?

Now that you mention it, you can do it with CSS media queries, like so (but with shape and path elements rather than image elements):

https://github.com/estelle/clowncar

You may not be able to make it look good at all resolutions, but it's often adequate to make it look good at some minimum and anything above. You can do that without hinting.

Not entirely true. A lot of times resolutions are just double the normal one, so the SVG image scales perfectly and looks good.

I have written my prev reply before I've seen yours.

Yes, if its mostly double-sized resolution then blurring shouldnt be a prob,

And when it is some strange "1.something" or "2.something" resolution, then probably also PNGs will look blurred, unles you dont supply exact special PNGs for such resolutions

Assuming it was hinted to the intended resolution. But that's still an extra step.

For 1px lines the only thing you have to remember is to put the points on half-pixels (annoying, but you can just wrap a <g transform='translate(0.5 0.5)> around your drawing if needed. The other thing would be shape-rendering='crispEdges' which also helps, but not everywhere.

Which you can't have in SVG since the format (IIRC) does not support any hinting. So it's down to luck, and the width of your lines.

Well, SVG's default coordinate space is defined in terms of CSS pixels, which explicitly allow for rounding to match (a multiple of) the device pixel size. So, if you align things to SVG pixels, they'll likely come out rounded to device pixels.

I've never had a problem with hinting, why does everybody consider it so difficult?

Also, basic hinting is not terribly difficult for the artist with modern font design tools. Similar tools could be provided for SVG hinting. Also, auto-hinting works pretty well. I have often wondered why there has been no effort to do the same thing with SVG renderers. At the very least, they could be rendered at 2X and then downsampled with a lanczos filter. The effect is not the same, but it's far from orthogonal.

But is hinting even possible in a format that supports multiple colors? It does not seem obvious to me that it is.

I see, it is an interesting point, thanks.

For me, that would be one of the main reasons against SVG

Except that all other image formats suffer the exact same problem. Some filters may be better tuned for different image types but there's no good, generic solution. Avoiding SVG doesn't solve this at all.

Reply on news.ycombinator.com