Hacker News new | comments | ask | show | jobs | submit login

The only thing holding back SVG is laptops. Most phones have enough pixel density that SVGs look great and are the right choice for most non-text, non-photo assets. But pixel density is low enough on most laptops that they look fuzzy. Low-end tablets have the same issue but no one really cares about hi-if experiences on those devices.

I think it often comes down to what's the easiest asset workflow that gets us a good result. From that perspective, 1x raster + 2x raster is less work than 1x raster + SVG




Why does an SVG look fuzzier than a bitmap at low resolutions? Is it because of the lack of anti-aliasing?


Because bitmaps target a specific resolution they can be tweaked so that features are aligned to pixel boundaries resulting in less anti-aliasing.

Truetype fonts are an example of a vector format that can still look sharp at arbitrary resolutions because they can include hinting programs that align the control points to pixel boundaries. This is why fonts tend to look sharper on Windows and Linux than MacOS X. Linux and Windows default to strong hinting, and MacOS X uses only slight hinting, preferring accurate shapes to sharpness.


> Linux and Windows default to strong hinting, and MacOS X uses only slight hinting, preferring accurate shapes to sharpness.

I know you already know these things, but for the sake of discussion (or other people).

Linux allows you configure hinting. It's true that by default (depending on how you define default) you get no hinting, but no reasonable distribution that I know of has shipped with that default for the past 7 years. Quite the opposite in my experience. Linux fonts (thankfully) look more like OS X fonts than Windows fonts.

Unfortunately, this configuration usually happens in some Gnome/Unity/XFCE/KDE configuration format, so if you want to use a better window manager with no DE, you sometimes have to recreate this from scratch, although, as someone who obsesses over font rendering and doesn't like the DEs, this is easier now than in 2000.

And then you have Google Chrome who just ships with its own font rendering. Gah.


It's pretty much the opposite. Too much anti-aliasing. At low resolutions, you need to be aware of the pixel boundaries to really make an image look good. Think 8-bit Nintendo/"pixel" art. You can't simply anti-alias a vector image down to a 8x10 pixel sprite. You just end up with a blurry mess.


Set your coordinates to 0.5 positions instead of whole pixels and look at the differences. Like if you draw a line from 100,100 to 200,200 try 100.5,100.5 to 200.5,200.5

For a quick glance, take a look at this nasty ultra-dense rendering in FF/Chrome and compare it to IE: http://projects.voanews.com/ebola-tracker/ (uses raphaeljs so renders in SVG or VML, whichever is supported.)


>Why does an SVG look fuzzier than a bitmap at low resolutions?

It doesn't -- it's the same as a bitmap in the default resolution rendered. And it gets even better when you zoom-in on those 'low resolutions'.


That is strictly true, but the beauty of a bitmap is that you can make it look better by rendering at a larger size and then scaling down. Effectively multisampling by hand. You can also do this as a preprocessing path in your asset pipeline and get better looking results than just using an SVG outright.

This is what we do for the cards at http://greenfelt.net. We lose a lot of detail in the face cards when we render them directly to the correct size as SVGs, especially at small sizes. There's a price to pay, of course, and it's a slightly more blurry look.

Another tangentially related but interesting fact is that every card set we have rendered as a pngcrushed png (except for the absolute largest size) is a smaller than the SVG source code.


>every card set we have rendered as a pngcrushed png (except for the absolute largest size) is a smaller than the SVG source code.

Considering SVG is XML and PNG is binary, I am not totally surprised. Does that still hold after gzip compression?




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: