AUTOMATIC1111
Lazy-load extra network preview images
Moves the extra network previews to an <img> so native lazy-loading can be used. For those that need every lora.
Environment this was tested in
- OS: Windows 10
- Browser: Microsoft Edge
Screenshots or videos of your changes
https://user-images.githubusercontent.com/4073789/227837988-63bbbf4f-54e0-423e-a39b-118f048f909e.mp4
To clarify, this makes it so that instead of all independent images being loaded at the same time by the browser when you open extra networks UI, only those that can be seen on screen are loaded, is that correct?
So this must be unrelated to #8781 then because you can start seeing results very early even without <img>. Is there a way to measure/see usefulness of this?
Here's without it. All the images load at once, whereas with <img loading="lazy">, they load only when they're visible.
https://user-images.githubusercontent.com/4073789/227881483-8de93943-18a9-454e-a6b0-6386fb03db76.mp4
No, I get that, but are there tangible advantages to loading them as you scroll? I personally for myself would prefer for everything to download right away, especially if otherwise you could get yet-uloaded images as you scroll.
In most cases not really, but according to #8781 it can be a problem when using it remotely and there are tons of them to load.
In most cases not really, but according to #8781 it can be a problem when using it remotely and there are tons of them to load.
Anyway to do "all" locally and "lazy" remote?
i'd be in favor of lazy loading - with smaller number of previews, its no different, otherwise its beneficial. there are ways to do lazy loading progamatically just ahead-of-time (monitoring onscroll and current position), but that would be too much javascript for here.
Fixes a lot of issues like #9055 and #9027 that completely freeze up all the settings components, seems like a very critical change
I'd still like to see this PR merged. For users with a ton of extra networks like myself, in the current state of the UI, just opening the panel invokes >2k requests and >2GB of images to be transferred. This is a huge no-no if you're running this remotely, and especially if you're attempting to access it from lower-powered devices such as mobile.
