[stockhorn]

I gave the webapp and android app a quick test. It looks nice, but it is still not as smooth as google photos or similar. E.g. the photos are not preloaded fully and I still need to wait a few milliseconds to get a photo fully rendered. (Also there is some white flickering when swiping through the photos on android)

I wonder how the big players do it. Of course they have a lot more manpower, but maybe the also have some clever caching/rendering lib..?

Kudos for doing this and opensourcing everything. I really appreciate this and I might stick around.

[vishnumohandas]

Thanks for checking us out!

We currently keep 2 versions of a photo - one the original, and the other a downscaled copy to be rendered as the thumbnail.

Unlike non-e2ee providers, we cannot transcode and serve optimised images on the fly, when it's faster to downscale than serve the original image over network.

What we could do is

1. Intelligently preload original photos when their thumbnails are in scope

2. Store an extra version of the photo, whose resolution is between that of the thumbnail and the original, and perform #1 over those

Sorry about the flicker, will fix it.

[stockhorn]

Ah this totally makes sense! Do you use progressive JPEGs already when opening the full image?

If only there was a progressive encoding which lets you get a perfectly downscaled (not blurry) version of an image by just reading parts of the file.

[vishnumohandas]

TIL about progressive JPEGs, will check it out, thanks!

We currently render the thumbnail first (in most cases it's available locally) and then replace it with the original image once fetched from remote, while replicating the zoom and pan operations (if any) performed by the user. So it is "progressive" in some sense, but goes from something like 20% to 100% in one shot.

("20%" is a simplification, the actual value will depend on the resolution of the original image and that of the generated thumbnail, the latter is fixed)