7 comments

• 

  Shog9

  2 years ago

  Huh? How is such a technique in any way useful for favicons? There's... only one.
  Are you thinking that it'd be groovy if you could store the favicon in the same image as other icons on the page? 'Cause i gotta say, that sounds like just a maintenance nightmare...
  reply
• 

  Paul Watson

  2 years ago

  No, not just one.
  
  The interface lists many other websites and we want to show the favicon of each of those websites next to the title.
  
  There can be up to 300 on one page though and that makes for a slow load time for the page as it makes 300 image requests. If I could route it through our server as a few single concactenated favicon images it would be better.
  reply
• 

  Shog9

  2 years ago

  oh. Ohhh....
  
  So you could do server-side concatenation of the favicons, generate CSS to display them at the same time, and send one moderately-sized image and one .css file down instead of 300 tiny images.
  
  I like it... :-D
  reply
• 

  Shog9

  2 years ago

  First thing that strikes me - you're talking over half a MB uncompressed for 300 16x16 indexed (8bpp) icons. Even if you can compress it down to only a tenth of that size, you're still talking 64KB of uncached image data - whereas, you could probably cache the plain favicons extremely easily.
  
  Of course, if it's *always the same 300 icons*, you can ask the browser to cache the concatenated image as well, and you're really ahead of the game. But assuming that isn't likely, the next best thing is probably to estimate a "sweet-spot" - how many images are likely to stay the same between each request? If users are generally viewing the same sites, this is probably fairly high - say 80%, or 240 images. Now, if you could group images into smaller sets based on their probability of being displayed, you can still generate the CSS and the images in a particular strip together, cache them server- and browser-side, relying on the browser pulling in however many sets are needed. The sets should be large enough to reduce the total number of requests, but small enough that it won't be too onerous if the browser has to pull down a few more than what would be optimal (total number of icons > 300).
  
  I suspect you could come up with a formula for this, though i'm not seeing it right now.
  
  Just when i think you're being utterly dull, you surprise me with an interesting little puzzle like this... :-)
  reply
• 

  Shog9

  2 years ago

  Ack, i didn't even think clearly - 8bpp is probably terribly impractical, since if you have more than a few icons using different palettes you'll end up having to choose a single palette and map them all to it. I've done this before, writing a tile manager for an old DOS game - it sucks, even when you have an artist you can ask to re-draw images for a given palette. Of course, these are tiny little icons, and most probably use just a handful of colors - but still, with 300 images, you're gonna have problems. Even just one icon like your green balloon thing would suffer if it had to share a palette with (say) a shaded red balloon.
  
  So you'd want to go with full-color. You could be talking 100KB for a full set of 300 images, maybe a little less, but probably in that ballpark. You'd *definitely* want to cache that somehow.
  reply
• 

  Paul Watson

  2 years ago

  Blimey, I sleep for one night and I come back to find you talking to yourself.
  
  Plenty of good points in there, Shog. It gets even more complicated because some favicons aren't 16x16. Salon's (http://salon.com/favicon.ico) is 32x32 and you do get better. Thankfully the interface is geared to only display 16x6, so we can scale it on the server.
  
  Also this is for a feed reader interface and most people don't change their subscriptions too wildly.
  
  Still, thinking about it more, I'm not sure there is a sweet spot and even if there was I'm not sure it would make it easy for the client-side CSS to display it correctly. You'd end up with a dynamically generated CSS file with 300 entries.
  
  hmmm.
  
  I think going back and changing the original problem is best. Displaying 300 favicons is stupid. At most 10-20 will be displayed on a screen at once with the rest hidden by foldering or scrolling mechanisms. They can load when needed, not on page load.
  
  hmmm. Might work.
  
  (16x16 annoyances they are.)
  reply
• 

  Shog9

  2 years ago

  Well, say your auto-gen CSS looks something like this:
  #BC7DDA8826EF4c0b8F452622B8B6C8CF { background: url(iconset1.png) -128 0; }
  
  ...for each icon. And it could probably be shorter. But even then, for 300 entries you'd have only about 22KB of CSS, which isn't even as bad as it sounds since if you want 300 images you'd have to associate them in *some* way anyhow, and it's not gonna get much more concise.
  
  Of course, you're right - you're not gonna have 300 icons on-screen at once, and a reasonable browser is gonna load the ones on-screen first - so you'll benefit from intelligent loading *and* caching browser-side.
  
  Still, an interesting little problem.
  reply