19 ms·

Good idea! To go further, you could cut the PNG into four strips (top, bottom, left, right) so the browser doesn't have to store the enormous rectangle of tran

by panic 12y ago

Good idea! To go further, you could cut the PNG into four strips (top, bottom, left, right) so the browser doesn't have to store the enormous rectangle of transparent pixels making up the insides of the PNG.

onion2k 12y ago
The few bytes you'd save on the png would be lost on the few bytes of additional markup you'd need in your html.
- nitrogen 12y ago
  The browser still has to store that uncompressed empty area though, so it would use more memory and probably take slightly longer to paint on a slow device.
  - Drakim 12y ago
    I was under the impression that PNG is actually quite good at compressing areas of a singular solid color (or in this case solid transparency). It just fails at every-pixel-is-different cases, where JPG is better. Furthermore, I'm pretty sure a slow device would take longer to paint four separate images due to the overhead of having four of them.
    - taejo 12y ago
      Nitrogen's point is that most (all?) browsers decompress the image in memory.
    - nitrogen 12y ago
      Furthermore, I'm pretty sure a slow device would take longer to paint four separate images due to the overhead of having four of them. Back in the old days of 2D game development, some games would use a technique called "dirty rectangles" to repaint selected areas of the screen that had changed. Windowing systems like X did/do something similar with "damage" or "expose" events (can't remember the exact name). It's because the logic to handle many separate small rectangles is less expensive than the loop and memory bandwidth to paint one big one.
    - panic 12y ago
      In order to draw the PNG, the browser has to decode it, including the transparent pixels. I'm also pretty sure (though I haven't tested this) that the overhead of painting four smaller images is negligible in comparison to the cost of blending the entire center area. Many sites are very bad about this, e.g. this sprite sheet from linkedin: https://static.licdn.com/scds/common/u/img/sprite/sprite_global_v8.png https://static.licdn.com/scds/common/u/img/sprite/sprite_glo... which, when decoded, takes up ~9MB of almost entirely empty memory. Check out the "Optimizing Web Content in UIWebViews and Websites on iOS" talk on https://developer.apple.com/videos/wwdc/2012/ https://developer.apple.com/videos/wwdc/2012/ for more info about not wasting memory on mobile web sites.

by panic 12y ago

onion2k 12y ago

The few bytes you'd save on the png would be lost on the few bytes of additional markup you'd need in your html.

nitrogen 12y ago
The browser still has to store that uncompressed empty area though, so it would use more memory and probably take slightly longer to paint on a slow device.
- Drakim 12y ago
  I was under the impression that PNG is actually quite good at compressing areas of a singular solid color (or in this case solid transparency). It just fails at every-pixel-is-different cases, where JPG is better. Furthermore, I'm pretty sure a slow device would take longer to paint four separate images due to the overhead of having four of them.
  - taejo 12y ago
    Nitrogen's point is that most (all?) browsers decompress the image in memory.
  - nitrogen 12y ago
    Furthermore, I'm pretty sure a slow device would take longer to paint four separate images due to the overhead of having four of them. Back in the old days of 2D game development, some games would use a technique called "dirty rectangles" to repaint selected areas of the screen that had changed. Windowing systems like X did/do something similar with "damage" or "expose" events (can't remember the exact name). It's because the logic to handle many separate small rectangles is less expensive than the loop and memory bandwidth to paint one big one.
  - panic 12y ago
    In order to draw the PNG, the browser has to decode it, including the transparent pixels. I'm also pretty sure (though I haven't tested this) that the overhead of painting four smaller images is negligible in comparison to the cost of blending the entire center area. Many sites are very bad about this, e.g. this sprite sheet from linkedin: https://static.licdn.com/scds/common/u/img/sprite/sprite_global_v8.png https://static.licdn.com/scds/common/u/img/sprite/sprite_glo... which, when decoded, takes up ~9MB of almost entirely empty memory. Check out the "Optimizing Web Content in UIWebViews and Websites on iOS" talk on https://developer.apple.com/videos/wwdc/2012/ https://developer.apple.com/videos/wwdc/2012/ for more info about not wasting memory on mobile web sites.