5 ms·

A commenter to that article (nolen) wrote: > I was involved in adding this to PNGs in ~2011 or so. I don't remember the details but you've got this pretty much

by my123 5y ago

A commenter to that article (nolen) wrote: > I was involved in adding this to PNGs in ~2011 or so. I don't remember the details but you've got this pretty much right. > The reason was indeed performance: on the first retina iPads, decoding PNGs was a huge portion of the total launch times for some apps, while one of the two cores sat completely idle. My guess is that it's still at least somewhat useful today, even with much much faster single-thread performance, because screen sizes have also grown quite a bit. Interesting that PNG parsing was a severe bottleneck a decade ago...

userbinator 5y ago
I'm surprised too; in the Windows world, two decades ago, "skins" were popular and those essentially turned every single UI element into a bitmap. On the hardware of that time, their impact on performance was pretty minimal. Of course, "every UI element is a bitmap" is not a good idea anyway, for other reasons, but seems to have someone become the norm for web and mobile.
- rp1 5y ago
  Bitmaps take memory, but are quite efficient from a runtime perspective because they aren’t encoded.
  - Retric 5y ago
    Bitmaps take both bandwidth and space, either can be an issue.
  - giantrobot 5y ago
    > Bitmaps take memory, but are quite efficient from a runtime perspective because they aren’t encoded. Memory and bandwidth. To decode/display an image it's got to be loaded from storage. In the case of a Retina display iPad that's 2048x1536px. With a 24-bit color depth that's a 9MB bitmap to load from disk (SSD or whatever). I just did a test with ImageMagick. The same 2048x1536 image encoded to an uncompressed Windows bitmap is 9MB while the same image as a PNG (PNG24, zlib level 9, with adaptive scanline filtering) is only 4MB. That's less than half the data to load off disk. Unless CPU power is at an absolute premium you're probably better off with an image with lossless compression rather than completely uncompressed.
    - rp1 5y ago
      True, bandwidth is a concern. It might be possible to copy memory directly from disk to the GPU, which may be more efficient.
      - giantrobot 5y ago
        Assuming the on-disk version of a graphic is compatible with your particular GPU. Even within the same manufacturer two generations of GPUs might not use the same image format. A generalized on-disk representation is safer and likely more forwards compatible.
    - seoaeu 5y ago
      > Unless CPU power is at an absolute premium you're probably better off with an image with lossless compression rather than completely uncompressed. Really depends on the exact situation. If your image decompression algorithm runs at 100 MB/s, but your disk bandwidth is 250 MB/s and you have plenty of space...
- mirashii 5y ago
  Bitmaps are special in that they don’t require a decompression step, so of course they don’t have the overhead of a decompression step.
  - Lammy 5y ago
    The alternative isn't a different raster image format — it's the native drawing commands of the underlying graphics system, like QuickDraw on classic Macs or GDI on classic Windows. They work like a plotter: moving a cursor to a position on the pixel grid and giving it drawing commands. You can see the residue of those old graphics systems in the various "metafile" image formats like PICT/WMF/EMF: https://en.wikipedia.org/wiki/PICT https://en.wikipedia.org/wiki/PICT https://en.wikipedia.org/wiki/Windows_Metafile https://en.wikipedia.org/wiki/Windows_Metafile
    - Talanes 5y ago
      > The alternative isn't a different raster image format Except that we're in a conversation about the relative resource consumption of bitmaps and png, not a conversation about what the best way to draw UI elements is.
    - charcircuit 5y ago
      >They work like a plotter: moving a cursor to a position on the pixel grid and giving it drawing commands. This isn't how GPUs work meaning it will be slow.
megablast 5y ago
It’s the first thing the app does. Or used to. Find an image and display to user while loading rest of the app.
PragmaticPulp 5y ago
> Interesting that PNG parsing was a severe bottleneck a decade ago... Bottlenecks are relative. If your goal is to shave a couple hundred milliseconds off of app launch times, eventually you have to start digging deep. It may not have been prohibitively slow, but for image-heavy apps it could have been the low hanging fruit that moved them closer to the goal.
- Wowfunhappy 5y ago
  Note also that, at least in 2011, all iOS apps would show a PNG poster image prior to loading the actual interface. So this may have been more about the "perceived" app launch time than the real one.
  - giantrobot 5y ago
    > Note also that, at least in 2011, all iOS apps would show a PNG poster image prior to loading the actual interface. So this may have been more about the "perceived" app launch time than the real one. The LaunchImage was definitely about perceived launch time of an app. The idea is you show an image that was similar to the main screen of your app and once the UI initialized it would just magically swap that for the static LaunchImage. So you'd want a really fast PNG decoder to be able to get it on screen and let the CPU do the work of initializing the application.
jonhohle 5y ago
That seems like an interesting use case for resource forks. Decompress once and store in a resource fork of the original PNG. If storage space becomes an issue, those resource forms can be purged along with other caches.

by my123 5y ago

userbinator 5y ago

I'm surprised too; in the Windows world, two decades ago, "skins" were popular and those essentially turned every single UI element into a bitmap. On the hardware of that time, their impact on performance was pretty minimal. Of course, "every UI element is a bitmap" is not a good idea anyway, for other reasons, but seems to have someone become the norm for web and mobile.

rp1 5y ago
Bitmaps take memory, but are quite efficient from a runtime perspective because they aren’t encoded.
- Retric 5y ago
  Bitmaps take both bandwidth and space, either can be an issue.
- giantrobot 5y ago
  > Bitmaps take memory, but are quite efficient from a runtime perspective because they aren’t encoded. Memory and bandwidth. To decode/display an image it's got to be loaded from storage. In the case of a Retina display iPad that's 2048x1536px. With a 24-bit color depth that's a 9MB bitmap to load from disk (SSD or whatever). I just did a test with ImageMagick. The same 2048x1536 image encoded to an uncompressed Windows bitmap is 9MB while the same image as a PNG (PNG24, zlib level 9, with adaptive scanline filtering) is only 4MB. That's less than half the data to load off disk. Unless CPU power is at an absolute premium you're probably better off with an image with lossless compression rather than completely uncompressed.
  - rp1 5y ago
    True, bandwidth is a concern. It might be possible to copy memory directly from disk to the GPU, which may be more efficient.
    - giantrobot 5y ago
      Assuming the on-disk version of a graphic is compatible with your particular GPU. Even within the same manufacturer two generations of GPUs might not use the same image format. A generalized on-disk representation is safer and likely more forwards compatible.
  - seoaeu 5y ago
    > Unless CPU power is at an absolute premium you're probably better off with an image with lossless compression rather than completely uncompressed. Really depends on the exact situation. If your image decompression algorithm runs at 100 MB/s, but your disk bandwidth is 250 MB/s and you have plenty of space...
mirashii 5y ago
Bitmaps are special in that they don’t require a decompression step, so of course they don’t have the overhead of a decompression step.
- Lammy 5y ago
  The alternative isn't a different raster image format — it's the native drawing commands of the underlying graphics system, like QuickDraw on classic Macs or GDI on classic Windows. They work like a plotter: moving a cursor to a position on the pixel grid and giving it drawing commands. You can see the residue of those old graphics systems in the various "metafile" image formats like PICT/WMF/EMF: https://en.wikipedia.org/wiki/PICT https://en.wikipedia.org/wiki/PICT https://en.wikipedia.org/wiki/Windows_Metafile https://en.wikipedia.org/wiki/Windows_Metafile
  - Talanes 5y ago
    > The alternative isn't a different raster image format Except that we're in a conversation about the relative resource consumption of bitmaps and png, not a conversation about what the best way to draw UI elements is.
  - charcircuit 5y ago
    >They work like a plotter: moving a cursor to a position on the pixel grid and giving it drawing commands. This isn't how GPUs work meaning it will be slow.

megablast 5y ago

It’s the first thing the app does. Or used to. Find an image and display to user while loading rest of the app.

PragmaticPulp 5y ago

> Interesting that PNG parsing was a severe bottleneck a decade ago... Bottlenecks are relative. If your goal is to shave a couple hundred milliseconds off of app launch times, eventually you have to start digging deep. It may not have been prohibitively slow, but for image-heavy apps it could have been the low hanging fruit that moved them closer to the goal.

Wowfunhappy 5y ago
Note also that, at least in 2011, all iOS apps would show a PNG poster image prior to loading the actual interface. So this may have been more about the "perceived" app launch time than the real one.
- giantrobot 5y ago
  > Note also that, at least in 2011, all iOS apps would show a PNG poster image prior to loading the actual interface. So this may have been more about the "perceived" app launch time than the real one. The LaunchImage was definitely about perceived launch time of an app. The idea is you show an image that was similar to the main screen of your app and once the UI initialized it would just magically swap that for the static LaunchImage. So you'd want a really fast PNG decoder to be able to get it on screen and let the CPU do the work of initializing the application.

jonhohle 5y ago

That seems like an interesting use case for resource forks. Decompress once and store in a resource fork of the original PNG. If storage space becomes an issue, those resource forms can be purged along with other caches.