Extra networks UI optimize #230
Conversation
Benefits are twofold: 1. Completely eradicates the startup cost of building the UI, it's only ever built when someone wants to use it for the first time 2. Drastically cuts back on the amount of data sent over the network when loading the webui page
Co-authored-by: Evan Stoll <evanjsx@gmail.com>
|
@space-nuko any chance you might create a new pr or update this one so there is no merge conflict? if not, i'll have to go through conflict resolution during merge and its messy since pr originated for a different fork. |
|
there should be a global approach-remedy for accordions destructive behavior that impacts performance layout and internal update I have created a function that applies to all instances and only called once to cache the contents, then it uses the hidden property as it was in previous version of gradio I was thinking doing the same with the dropdown fields you can check ui.js |
|
Just in case you weren't aware there's performance impact if gradio sends a huge initial HTML bundle when the user connects, for example in the case of the user having thousands of LoRAs this can be upwards of 15 seconds. And this can even cause timeouts on server startup because gradio internally checks for connectivity on its own listen address, and if that times out (because of how long it takes to reify the extra networks HTML) it just exits the process entirely |
|
yes I am aware I am not against paging just noted that defer loading of images aka lazy loading can improve even further the performance and the global approach for accordion that will work for existing extensions that haven't been updated and in all cases that is exists and may cause issues like removing the custom attached listeners in the contents of accordion when it is closed |
|
closing this pr as @anapnoe is working on alternative/more-generic approach. |
along with new keybind functionality for quick jumping between sections. Closes vladmandic#230
AUTOMATIC1111/stable-diffusion-webui#8742