7 ms·
Perhaps there needs to be a new standard for pngs where you can have one image for each subpixel order. Or we can get everyone to use RGB. Either would work.
by windsurfer 17y ago
Perhaps there needs to be a new standard for pngs where you can have one image for each subpixel order.
Or we can get everyone to use RGB. Either would work.
- rbanffy 17y agoWhy not just reference a larger .png file in your HTML and let the browser deal with the specifics?
- yangyang 17y agoThe bigger download would slow things down. Not sure if image resizing could even make sensible use of sub-pixel rendering...
- rbanffy 17y agoA 32x32 PNG would not be that much larger than a 16x16.
- dangrover 17y agoIndependent of subpixel rendering issues, a good iconographer will tweak an icon at different sizes, even if they originally created it from a vector. Pixels do matter.
- amalcon 17y agoThis problem would also be solved by actual widespread support for SVG or something similar. With vector rendering, we can just let the client handle any subpixel business.
- potatolicious 17y agoWhen you're trying to communicate a handful of pixels of information why send the entire (complex) vector file?
- amalcon 17y agoFor the exact reason I stated: portability. Bitmaps are good for some things, but logos aren't really one of them.
- potatolicious 17y agoBut in this case we're talking about a logo that's going to appear a few pixels wide on all clients - there's really no incentive to add the overhead of a large file transmission (not to mention the requisite client-side processing). In a everything-is-made-of-marshmallows ideal world, yeah, bandwidth is not an issue, nor is site load time, and client-side CPUs and RAM are infinite. In that world I too would transmit everything, no matter how minor, in vector form. We do not live in that world.
- amalcon 17y agoThe YouTube favicon.ico is 318 bytes long. I threw together a crappy SVG mockup of the logo with absolutely no size optimization, and it clocks in at 429 bytes. When gzipped, they clock in at 233 and 248 bytes, respectively. If you're worried more about the 15 bytes than about compatibility, then just have the logo scale up and use it for your main logo as well; it should actually save bandwidth that way.
- dflock 17y agoSomething that people often forget when dissing vectors and SVG in particular, is that they're _scalable_ - so you can use the same version everywhere. So, you send the logo SVG once, and you could use it for the main logo on the homepage, smaller footer logo on the rest of the site AND for the favicon, because it'll scale. Browser just downloads one SVG file once, instead of 3 different bitmaps. Obviously, this is in everything-is-made-of-marshmallows ideal world where Internet Explorer doesn't exist, but hey.
- zokier 17y agoTechnically SVG is scalable, but not in practice. Small icons need different design than large icons, and SVG doesn't solve that. Look at fonts, they have hinting system to indicate changes for different sizes. Without similar system, SVG can't produce icons that truly are scalable. It's especially important in small icons like favicon(16x16px) which I believe will be hand drawn for long time. I think that Apple does resolution independent icons by embedding several bitmap versions with a vector version in their icon files. That's the way to go in desktop applications, but similar system would produce too much overhead without significant advantage in web.
- twak 17y agoAnother solution is to put the pixel order in the html header. A smart browser showing the same page spread over two different monitors would then download twice as much, but everyone else would be happy.
- rbanffy 17y agoNo. HTML has no reason to specify information that has meaning to display technologies we happen to use now. Subpixel anti-aliasing is based on current LCD technology and doesn't even deal with newer approaches such as the PixelQi screen that equips the OLPC laptop (9 subpixels per pixel). This solution would pollute the HTML information space.