This is sort of an architectural/conceptual question regarding how a system (specifically a web browser) handles compressed images.
We’re dealing with an “image gallery” web app at work that has eleven 1920×1080 images on a page that you can swipe through on an iPad. We’re finding it to be extremely slow and I’m almost certain it’s because the iPad is having trouble with having so many large images in memory and on the page at the same time.
Some have suggested we compress the images more; they’re currently PNGs, and they want to recompress them to JPG. Obviously the file size will be smaller, but unless the iPad (and others) have a way of directly rendering a compressed image to the screen (frame-buffer), I’d think they’d have to decompress the image into memory before rendering. In that case, it seems like the compression wouldn’t affect the performance of rendering them. (Other than the slight added processing power of decompressing them “more”.)
Is my understanding and assumptions correct? Should we resize, or recompress the images?
Thanks
More information- read this before you tell me “yeah compressed images are smaller” – I’m a developer, not a user:
Using less space is not the same as using less memory. We’re not having a problem with storage, we’re having a problem with performance of rendering. The code is simple and just animates between one div and the next to give the “swipe” effect to the gallery.
When we remove the images from the equation, the performance is fine; so I’m fairly certain the bottleneck is the images, not the code.
The question being asked is “does compression make the image use less memory” because others want to compress the images more to gain performance. As far as I understand the architecture of compression though, you still have to decompress it to its original size in memory to use it and thus the compression does not affect memory usage; only storage and transmission.
No, the image will use the same amount of memory (alas pixels) if displayed on a monitor for example.
Compression applies to the container of the image, usually a file or a temporary memory buffer, but on screen it uses the same.
This is because you need to allocate each pixel to be displayed.
For an 1920×1080 image in 24-bits it will use 1920 x 1080 x 3 bytes (one byte for each color component in RGB -> 1 byte = 8 bits), or 6,220,800 bytes (roughly 6 mb).
It will not take less space in memory when displayed but can be faster to load into memory. But that’s about it.
Now the application need to decide if it will decompress it only when shoing the image (which will cause a lag) or decompress all and be able to display them instantly. This decision is application based so you will need to the check the specific application.