Update Gradio to 3.23.0

[space-nuko]

Describe what this pull request is trying to achieve.

Huge webui update, bumps Gradio to version 3.23.0

Impressions so far:

• Seems somewhat more responsive than 3.16
• Lots of UX issues (blank space, huge page margins causing squished elements and rampant text overflow, dropdown bugginess)
• Also a lot of UX improvements stemming from new event handlers (use .release() instead of .change())

Additional notes and description of your changes

Changes made:

• Converted webui's style.css to SCSS for easier maintenance, also supported in extensions now (style.scss)
• Updated CSS to be closer to current Gradio version's UX
  • Increased dropdown list size, cut down on dropdown item padding
  • Adjustments to tool button sizes/borders
  • Fixes for quicksettings bar
  • Merged in auto's CSS changes from his 3.22 branch
• Added a CSS Hotload button to the UI, recompiles all webui/extension (S)CSS on the backend and injects it dynamically (lost on page reload)
• Changed quicksettings sliders to only apply values when mouse is released, greatly improves UX
• The Custom Code script now uses Gradio's new gr.Code element
• New config option to support Gradio's theme API
• Removed one of auto's hacks for preserving the selected gallery image (it addressed https://github.com/gradio-app/gradio/issues/2984)
• Removed another one of auto's hacks related to canvas resizing (it addressed https://github.com/gradio-app/gradio/issues/1721)

Known extension issues:

• dynamic-prompts extension in its current state causes infinite recursion, patch filed at https://github.com/adieyal/sd-dynamic-prompts/pull/316
• Tag Autocomplete extension needed changes, patch filed at https://github.com/DominikDoom/a1111-sd-webui-tagcomplete/pull/141
• Depth Library extension's canvas gets cut off on the right side due to the new page margins
• Image Browser extension causes massive slowdown, and quicksettings never load

Known bugs:

• ~~img2img is broken, I think due to the submit_img2img JavaScript not being compatible~~
• ~~Gallery lightbox modal doesn't work~~
• ~~Send to img2img is broken~~
• ~~Sending parameters from PNG Info is broken~~
• ~~Pasting params.txt with the arrow button is broken~~
• ~~Show all pages in Settings tab no longer works~~
• Weird styling in Extensions tab table

Environment this was tested in

• OS: Windows
• Browser: Chrome, Firefox Nightly
• Graphics card: NVIDIA RTX 3090

Screenshots or videos of your changes

Old webui theme ported by AUTOMATIC1111 (current):

Monochrome (using Gradio's theme API):

Gradio's default theme:

[Sakura-Luna]

I tried installing sass and found that it requires a native build install, and since it was last updated in 2014, apparently it's no longer maintained, I don't think introducing an outdated dependency that requires a build is a good option.

[space-nuko]

2014? The one I installed from pip was last updated two weeks ago

https://github.com/sass/libsass-python

Maybe the lack of significant updates means it's just feature complete, regardless I think SCSS made it far easier to patch the stylesheets for this merge, could just make it a compile-time step and version the output .css instead

[Sakura-Luna]

On pypi, sass points to this https://pypi.org/project/sass/#history

[space-nuko]

The one I added was named libsass

https://pypi.org/project/libsass/#history

[Sakura-Luna]

It seems that it needs to join requirements.txt to avoid misunderstanding.

[space-nuko]

I did put it there though

https://github.com/AUTOMATIC1111/stable-diffusion-webui/pull/8752/files#diff-2284b86f286dc7e0ea4bd09a0ec20c78fbb17d6724d7f0053e78428d0715bbb1R31

[Sakura-Luna]

Somewhat confused, I don't seem to notice a performance improvement, when I open the page after waiting for create ui to complete, it still looks like it's loading. By the way, this loading animation hopes to be blocked to keep it consistent with the official version.

Looks like it still needs a lot of css fixes like rounded corners for some widgets, hyperlink colors and checkboxes etc.

[space-nuko]

Yeah by "smoother" I meant less of a delay when for example selecting a script that injects a whole lot of UI elements onto the page, the quicksettings thing is weird and I don't know what's up with it

[space-nuko]

when I open the page after waiting for create ui to complete, it still looks like it's loading

If you happen to have a lot of extra networks I think #8742 might fix that, I'm no longer encountering those loading transitions for more than a split second on page load

[hithereai]

Looks awful on my monitor (4k 42inch):

And I can keep going, basically all tabs are broken, visually.

Also the centering of the entire ui is probably a bad idea. We lose precious real-estate esp when working with many open windows.

[Sakura-Luna]

@hithereai Apparently it needs many css fixes, can you fix it?

[anapnoe]

@hithereai Apparently it needs many css fixes, can you fix it?

https://github.com/gradio-app/gradio/discussions/3097 better wait for the next release as gradio may introduce DOM changes to the components which possibly will break whatever changes made

[Sakura-Luna]

gradio-app/gradio#3097 better wait for the next release as gradio may introduce DOM changes to the components which possibly will break whatever changes made

@anapnoe I think you misunderstood the meaning, he refers to not controlling the consistency of css between versions, not "the next version".

[anapnoe]

gradio-app/gradio#3097 better wait for the next release as gradio may introduce DOM changes to the components which possibly will break whatever changes made

@anapnoe I think you misunderstood the meaning, he refers to not controlling the consistency of css between versions, not "the next version".

The DOM might change when we release the next version, we do not version it nor can we guarantee its consistency between versions as I understand it when DOM changes chances are css selectors become invalid for example consider tabs that have a kind of inefficient DOM structure tab buttons and tabitems are on the same level of selectors, in order to select the tab buttons #tabs > div:first-child button is the only selector that works the id containing all the tab buttons is not existent css selectors are flex border-b-2 flex-wrap dark:border-gray-700 which is generic applied to other elements as well my point is if I wanted to improve the structure of tab component the first think I would do is to separate the tab-buttons and tab-items to do that I will have to create parent element for tab-items all the selectors that you refer them as div + div or div > div + div are prone to break when DOM changes and is hard to debug cause they work but for other target divs I think gradio is doing a great work towards the right direction but it will take some time as all good things are

[space-nuko]

Looks awful on my monitor

Personally I don't mind the style changes as much (save for the numerous bugs), I also have a 4k monitor, 32-inch. I think this is what gradio's theming API is supposed to address isn't it? Maybe it'd be better to have a legacy and "default Gradio" theme integrated so people's workflows aren't impacted

The DOM might change when we release the next version, we do not version it nor can we guarantee its consistency between versions

This has basically already happened as I was making the changes for 3.22.1, it wasn't a straightforward port. Again seems like the theme API is supposed to fix this by allowing custom styles to be attached. Doesn't seem like there's much that can be done but fix everything that breaks when Gradio releases a new version, and try to future-proof things with their theming API where possible

https://github.com/gradio-app/gradio/discussions/3097#discussioncomment-5369369

What. I didn't know auto was working on 3.22 at the same time. Maybe we should collab?

[space-nuko]

Updated to use auto's CSS from his branch, check the preview

[Sakura-Luna]

After testing, the image browser extension will keep the page stuck loading.

[space-nuko]

Fixed an issue that caused infinite recursion with that extension, but the performance on page load is still very bad. I'm noticing it's trying to load a bunch of images from my outputs folder on startup for some reason.

[space-nuko]

@Sakura-Luna how many rows/columns do you have configured for the image browser in your settings? It started working again for me when I put 6/6. (The "Minimum number of pages per load" option doesn't seem to do anything in that fork) Probably a performance issue with new Gradio at this point.

[Sakura-Luna]

In my case it's still loading all the time, 6/6 gradio 3.22.1.

[Cyberbeing]

The temporary file behavior seems even worse in Gradio 3.23.0 than it was in 3.16.2.

Similar to 3.16.2, Gradio 3.23.0 still ignores Directory for temporary images in settings, but now it also creates a bunch of empty folders in %TEMP% on startup, while also placing every saved image into a separate folder next to a 0 byte tmp file. If you are able to fix both these issues in your pull request and force Gradio to use a single temp folder (default or specified), that would be great.

[Cyberbeing]

Another regression from 3.16.2 I've noticed, is when clicking an image to view it zoomed in during generation, the zoomed in image does not refresh with the new image when generation finishes.

[Sakura-Luna]

Another regression from 3.16.2 I've noticed, is when clicking an image to view it zoomed in during generation, the zoomed in image does not refresh with the new image when generation finishes.

This is not a problem introduced by gradio 3.23. The current version exists https://github.com/AUTOMATIC1111/stable-diffusion-webui/issues/8162, and it has nothing to do with zooming in. I think it may be a program logic error.

[Cyberbeing]

This is not a problem introduced by gradio 3.23. The current version exists #8162, and it has nothing to do with zooming in. I think it may be a program logic error.

The issue you linked is something different than the problem I just described with gradio 3.23. What I'm describing is:

• Click Generate
• Click current image result in txt2img_gallery to view it zoomed in modalImageFullscreen overlay while Generate is in progress
• Generate finishes and refreshes txt2img_gallery result, but not modalImageFullscreen zoomed view

With 3.16.2:

• Click Generate
• Click current image result in txt2img_gallery to view it zoomed in modalImageFullscreen overlay while Generate is in progress
• Generate finishes and refreshes both txt2img_gallery result and modalImageFullscreen zoomed view

Sometimes that automatic zoomed refresh behavior does break in 3.16.2, but usually it works. When testing 3.23 the modalImageFullscreen zoomed view never refreshes until you close and reopen the zoomed view which is a regression.

I've never had the problem of the result window txt2img_gallery not refreshing which you describe in your bug.

[space-nuko]

The temporary file behavior seems even worse in Gradio 3.23.0 than it was in 3.16.2.

Seems like this PR might address some of those problems: https://github.com/gradio-app/gradio/pull/3523

Gradio 3.23.0 still ignores Directory for temporary images in settings

Could you elaborate on what's the expected use for this feature? Is it to store the "temporary previews every N steps" images? I'm a bit confused as to what temporary files are left out of the normal outputs folder that are important to keep

zoomed in image does not refresh with the new image when generation finishes

Should be fixed by 41e24e2

[CapsAdmin]

Gradio 3.23.0 still ignores Directory for temporary images in settings

Could you elaborate on what's the expected use for this feature? Is it to store the "temporary previews every N steps" images? I'm a bit confused as to what temporary files are left out of the normal outputs folder that are important to keep

I think he's talking about gradio using the temp directory to store images so that gradio can properly serve image previews to the frontend. The problem is that the webui doesn't clean it up, so even if you disable image outputs, gradio will still store image outputs in /tmp/

as a workaround I do the following (on linux)

def prepare_environment():
    os.environ["TEMP"] = os.environ["TMP"] = os.path.abspath(os.path.join("outputs", "temp"))
    os.makedirs(os.environ["TEMP"], exist_ok=True)

in ./launch.py

So when I want to cleanup I can just delete the outputs/temp folder

[Cyberbeing]

It's not image previews which end up in the temp folder, but rather files served as downloads whenever you hit the SAVE or ZIP buttons. So ultimately what Directory for temporary images should be doing is overriding the directory which Gradio serves image/zip file downloads from.

As for why Gradio 3.23.0 was generating a mass of empty temp folders on startup which were never used, I have no clue. Hopefully it does have something to do with the PR you linked, but ultimately if we could override Gradio's temp folder location, this strange empty file/folder behavior wouldn't matter much even if never fixed.

Currently Graido always dumps temporary files (images/zips you save) into %TEMP% on Windows which is never cleaned up.

• Generate Images
• Press Save/Zip
• Gradio Dump your Image/Zip into %TEMP% which it then serves as a download
• These temp files are never cleaned up automatically, resulting in rather extreme storage usage and I/O overhead over time if you save a lot of files

As far as I can tell, this problem of Gradio ignoring custom temp folders may have started webui migrated to Gradio 3.16.2. The webui code for Directory for temporary images would appear to have no effect on current Gradio.

For the webui use-case this behavior is very inefficient, since for single images in particular there is no reason to duplicate them in %TEMP% when they already exist in /output/ (i.e. the same image displayed as in txt2img_gallery could be directly served as a download, but Gradio seems unaware these files exist). In fact, if you just right click save as on the gallery result image, rather than click the save button you avoid this temp file problem entirely. Unfortunately, no way to avoid temp files with saved zips since they are generated on the fly.

If the Directory for temporary images setting were working, you'd be able to specify a custom temp folder for Gradio to prevent it from dumping any temp files or folders into system %TEMP%. This would then allow you to use the webui option to automatically clean your custom temp folder on startup.

as a workaround I do the following (on linux)

CapsAdmin's brute force solution doesn't seem like a bad idea for webui to potentially implement in order to override the system temp folder reported to the entire python venv, if Gradio's temp behavior cannot be fixed. This is under the assumption that it works on Windows as well, and python libs which use the default temp folder won't break. Though a change such as that would go beyond the scope of this pull request. Since the problem is Gradio, hopefully there is a way to solve this issue within Gradio itself.

[space-nuko]

Thanks for clarifying, filed a Gradio feature request https://github.com/gradio-app/gradio/issues/3597

[space-nuko]

@Sakura-Luna

In my case it's still loading all the time, 6/6 gradio 3.22.1.

I think it's because that fork has some kind of weird concurrency issue in the JavaScript with latest Gradio, try https://github.com/nightglimmer/stable-diffusion-webui-images-browser instead?

[AlUlkesh]

@Sakura-Luna

In my case it's still loading all the time, 6/6 gradio 3.22.1.

I just made a new install with this pr. I don't see any slowdown on the image browser. This is on Gradio 3.23.0.

Was this perhaps the first time you used a newer version of the browser on a very large directory? On the very first access of an image directory it will populate the database with the exif info of every single image, which can take a while. But after that it should be fast.