Mostly you shouldn't have to hide backend latency by reordering, and if you don't reorder, you can just use JPEG image strips/sprites, which don't need double compression. JPEGs also stream, but in an order determined by the client, not the server. In my experience, Dropbox is quite a bit slower (by 10-20x) than services optimized for serving images - using 1500ms to deliver a 25k file is very slow on the web, but it…
We thought of spriting the thumbnails on the server, but this introduces a few problems: - All thumbs would have to be available on the server before the sprite can be encoded, which defeats progressive rendering. (Progressively encoding JPEG might be a possibility, but this isn't something we explored.) - The additional cost of encoding/decoding a large image on the server/client. -- Ziga (author)
2) How is it any more work to encode? It's the same total number of pixels and the memory footprint isn't that large for server or client.
I don't mean to dis your efforts, looks like you've done some nice work that performs well.
I just think cloud/media management is an interesting problem with a lot of different ways to look at it.