Thumbnail sizes

[Gusted]

Describe the change you'd like:

Let's generate 2/3 more pictures of each screenshot. These would be downscaled to 2/3 hardcoded dimensions, This will help for things that frequently requests screenshots, but actually don't need the full scale picture(style cards on USw, Inline search of stylus). I was thinking about 2 dimensions for the thumbnails.

• "large", a thumbnail which should match the dimension of our current stylecard's screenshots, which we will largely use.
• "small", a thumbnail which should roughly match the dimensions of stylus's inline search preview, which Stylus can use.

To avoid too create many thumbnails, we will only generate thumbnails for the current best format, webp.

CC @vednoc @narcolepticinsomniac

[vednoc]

How do you plan to store them? I would like to do it right by making it extendable for the future use-cases (user avatars, userstyle screenshots #17, and other places such as reviews/discussions/forums). We probably won't need small/large images in those places, but having it as an option certainly wouldn't hurt.

[Gusted]

How do you plan to store them?

1_thumbnail_small.webp

I would like to do it right by making it extendable for the future use-cases (user avatars, userstyle screenshots #17, and other places such as reviews/discussions/forums).

We could store different bits of pictures into their own folder structure.

We probably won't need small/large images in those places, but having it as an option certainly wouldn't hurt.

Currently we are having good amount of requests to the images which currently can still be a far amount in size.

[vednoc]

1_thumbnail_small.webp

That essentially what we have right now, which doesn't play well with caching. Especially now that images are cached for 3 months, some users could see an outdated image. It's not a huge deal for our platform, but I would prefer that we have proper caching.

We could store different bits of pictures into their own folder structure.

Yes, that could be the way to do it. If we hash their names, like the example I showed you a while ago, we probably wouldn't need to do that.

Currently we are having good amount of requests to the images which currently can still be a far amount in size.

That's true. Thumbnails would be way smaller and faster to load, especially for those on slow connections. That said, we still have a long way to go before bandwidth becomes a concern, so this implementation shouldn't be rushed.

[Gusted]

Especially now that images are cached for 3 months, some users could see an outdated image

I've added a comment into that 3 months caching that we can safely assume that images aren't updated that often.

It's not a huge deal for our platform, but I would prefer that we have proper caching.

How will you'd like to see it.

Yes, that could be the way to do it. If we hash their names, like the example I showed you a while ago, we probably wouldn't need to do that.

Eek, I'd like to hold of on hashing, as hashing is commonly used for distributed storage and if we ever need it, I'd like to combine those 2 hashes to avoid creating multiple hashes of something.