You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
One problem with proxied thumbnails is that it would involve a lot of requests to the Companion server. This could be mitigated with one of either:
Make sure that we only fetch thumbnails for the images that are currently in-view in the HTML. When scrolling fast we probably need a debouncing/throttling
Use batch endpoints where available, still need to render only those currently in-view and debouncing/throttling when scrolling
If we simply proxy the full images, it would lead to high bandwidth usage for the client (e.g. if the user is trying to view thumbnails for 10MB images), which is unacceptable, so we need to either
specify a size parameter to the URL before proxying it (not all providers support this)
compress it in companion using e.g. sharp (cpu intensive and could be a security risk).
Make sure that we only fetch thumbnails for the images that are currently in-view in the HTML. When scrolling fast we probably need a debouncing/throttling
We already use loading="lazy" on <img> tags so we already have this without any additional complexity.
Many providers are missing thumbnails. When users upload images (which is quite common), this makes the UX not very good.
There are two different kind of thumbnails that could be shown:
Browsing files
When selecting files in the native Google picker UI:
Selected files
After having selected files, in the Uppy UI:
<img>
cannot do.Proxying
One problem with proxied thumbnails is that it would involve a lot of requests to the Companion server. This could be mitigated with one of either:
See also #5389
Alternatives
Make a Transloadit-backed integration for rendering thumbnails
The text was updated successfully, but these errors were encountered: