We're in an icon-sharpness limbo

http://simurai.com/post/19895985870/icon-sharpness-limbo

by tbassetto • 14 years ago

41 22 14 years ago

WiseWeasel6• 14 years ago

I think the answer is SVG for anything we've got vectorized, and I've started delving more deeply into the format, which turns out to be pretty awesome.

First, to create them, I draw icons with vectors at the actual size the final icon will be rendered on regular non-retina displays, then export as SVG with Illustrator. But what I really want are the paths; fill and stroke colors and shading effects can be added manually.

Then, I open the SVG output in a text editor, and since it's all XHTML formatted, I can easily modify everything to get the look I want. I can re-organize the path and fill elements, change their fill colors, and add things like shadows right in the SVG file as filter elements, in case your editor makes sub-optimal choices as to how to encode your design.

These icons look perfect when rendered on both normal screens at 1x and retina displays at 2x resolution. If I needed an in-between size, I'd have to design a new vector for the new target size. One vector design will typically not work well for different rendered sizes at this small scale, as every pixel counts, and anti-aliasing does more harm than good. That problem is just unavoidable, even when you try to make a flattened PNG at all these in-between sizes.

I've also found SVG ideal for small bits of text with special non-web-safe fonts. Converting text to paths and exporting to SVG is the way to go over gif or png text, and looks great on retina displays.

luminarious• 14 years ago

As SVG supports CSS and Media Queries, it's possible to optimize the display for different display sizes. Like demonstrated here: http://my.opera.com/ODIN/blog/2009/10/12/how-media-queries-a...

WiseWeasel6• 14 years ago

Holy crap, that's awesome! Looks like I've got a new rainy Sunday project. Thanks!

WiseWeasel6• 14 years ago

OK, I take back what I said. SVG can be used to create a single asset that looks good at ALL resolutions; it's just going to take some work and possibly add too much bloat to be worth it in some cases.

So let's say you have a 16px icon design, with an element 7px wide, and you want a 24px version of that icon. The problem is when you scale an odd-numbered-height or width element by a factor of 1.5 in this example, you get an element with a height or width defined as a non-integer (10.5px wide in this case), which is when anti-aliasing kicks in and replaces that extra .5 pixel of element and .5 pixel of background with one pixel of element at half opacity. this makes it look fuzzy.

What you need to do is have a media query like this in the SVG file:

    <style>
    @media screen and (max-width: 24){#element {width: 10px}}
    </style>

Or maybe:

    @media screen and (max-width: 16){<shape id="element" width="7px"</shape>}
    @media screen and (max-width: 24){<shape id="element" width="10px"</shape>}

I haven't played with it to be sure yet, but something like that might allow you to set the width, height or radius to an integer for the sizes you care about.

Complex paths would still likely need to be redrawn for various target sizes to get rid of the more egregious anti-aliasing issues. In that case, we're adding bloat to everyone's SVG files to serve the needs of different clients. Maybe we're still better off with different SVG files served to different clients when we pass a certain threshold of duplicated content within the SVG, and duplicated paths would seem to me to be in danger of crossing that threshold.

alexchamberlain6• 14 years ago

We need a multi-resolution image format and/or support for browsers to dictate to the server what size they want.

ars• 14 years ago

There is a workgroup working on it: http://www.w3.org/community/respimg/

Some of the options: https://etherpad.mozilla.org/responsive-assets

alexchamberlain6• 14 years ago

We need to send the dimensions with the image request. It's the only way.

ricardobeat2• 14 years ago

We can already do that with media queries, it doesn't solve the vector anti-alias/detail problem.

WiseWeasel6• 14 years ago

Actually, the media queries only work for CSS image properties, like background-image, not for HTML img elements. We do need something equivalent to HTML5's handling of video, where you just stick a bunch of different paths to various formats in the video tag, and the browser selects the best one. Something like that for images would be nice; now we have to resort to jQuery hacks.

LachlanArthur• 14 years ago

Multi-resolution => maybe similar to .ico?

mmahemoff• 14 years ago

I'm curious if there are any standards for "patching" vector graphics. So you could download the base SVG and a separate vector and/or bitmap-based patch to produce something appropriate for the resolution. (As well as being appropriate for the bandwidth constraints etc.)

The patch could be downloaded simultaneously or progressively, i.e. after the base image has been rendered.

natevw• 14 years ago

I've always wondered if adding something like "font hinting" would cover most use cases. Although I suppose for e.g. icons sometimes at the smaller sizes the actual graphic is pretty much a completely different image, rather than just a hand-tweaked rasterization.

schmerg• 14 years ago

See http://www.pushing-pixels.org/2011/11/04/about-those-vector-... for a detailed exploration of precisely the issue with icons and real-life examples of how smaller versions are actually different images (eg a large 3d image with drop shadows gets gradually flattened to a simplified 2d version).

One thing you can do for patching SVG is to have multiple versions of images/shapes and use CSS rules to select just the most appropriate one to show depending on a class you add to some root or parent item - hiding the other until needed. I haven't tested this, but wonder if the browser would be smart enough to prioritise loading of the different images depending on the visibility.

Otherwise you could generate those parts of the SVG as required, and use the load event to only swap the display to the more appropriate version of an image once loaded.. hence as you zoom the display, you first get the "core" image/shapes etc simply scaled by the browser, and then as background images are loaded, these scaled versions are replaced by more appropriate versions.

This would match the way that zooming works with tiles in apps like Google maps - when you first zoom in you simply get the base tile images scaled by the browser, and then replaced by the more detailed versions as they're loaded.

We're in an icon-sharpness limbo

Related Stories