Too much logging in javascript causes UI to be unresposive to inputs, often taking longer to enter a prompt then it takes to render

losmurfs commented 2 years ago

Describe the bug Javascript console full of: "Fetch finished loading: POST ""." New entry added at least every second

To Reproduce Steps to reproduce the behavior:

Go to http://localhost:7860 (or URL you have configured)
Open your browser's javascript console, click on info if filtered
Or perform step 1 on an iPhone, after about 20 seconds, enter a 10 word prompt
After about 10 seconds, try to edit that prompt by inserting words in the middle, pasting word into prompt, selecting words and phrases to Cut. You will find that it has effectively become unusable.

Expected behavior All console.log entries in javascript code, weather generated in Python or contained within static Javascript files, that are not related to an error condition should be within an if statement that by default is not executed and is only executed when enabled by a global debug or verbose flag. On desktop browsers this is not usually a problem, unfortunately on many mobile browsers, even when the console is not viewable, all console output is stored in browser RAM (perhaps to facilitate debugging via external developer tools like XCode) causing the browser to reach the memory limit assigned to it by the OS causing it to have to swap between RAM and storage.

Screenshots

Desktop (please complete the following information):

OS: (Windows/Linus/macOS) no problem, (iOS) nearly unusable
Browser Too verbose in Chrome, Edge, Safari; Unusable in iOS Safari, Chrome, Duck Duck Go
Commit revision [looks like this: e68484500f76a33ba477d5a99340ab30451e557b; can be seen when launching webui.bat, or obtained manually by running git rev-parse HEAD]

Additional context The ideal UI for something that isn't instantaneous is best used on a smart phone

dfaker commented 2 years ago

I'm not seeing any unexpected console info entries being generated by the fetch calls within Gradio, a quite reasonable one per /predict/ request on the current build, and zero being generated by simply editing the prompt.

losmurfs commented 2 years ago

I'm not seeing any unexpected console info entries being generated by the fetch calls within Gradio, a quite reasonable one per /predict/ request on the current build, and zero being generated by simply editing the prompt.

the typing doesn't generate console output. The console output swamps iOS Safari, unless it is something else that prevents iOS Safari from working as well as desktop or just about any other website

losmurfs commented 2 years ago

I pulled and tested again, can't reproduce either

losmurfs commented 2 years ago

https://youtu.be/QLsUajxKsDM

Screen capture of the issue, steps to reproduce: On iOS Safari, enter a prompt, set resolution to 768x1024, set batch to 16, tap Generate, when it finishes, try to edit the prompt

dfaker commented 2 years ago

Slightly clouded by 16 base64 encoded representations of 1024x768 pngs hanging around the dom rather than the debug lines, is this reproducible with lower image sizes and more steps?

dfaker commented 2 years ago

I mentioned in the other issue, but do we want to try putting this:

#txt2img_gallery img, #img2img_gallery img {
    object-fit: scale-down;
    image-rendering: pixelated;
    image-rendering: optimizespeed;
}

At the end of your style.css and see if there's any performance improvement? There will be a slight image downgrade (outside the fullscreen preview) though.

losmurfs commented 2 years ago

I think the CSS will only effect rendering, the images will still occupy the same amount of space. I think the best approach would be to just provide an option to disable the gallery via the UI

On Tue, Sep 27, 2022 at 2:26 PM DepFA @.***> wrote:

I mentioned in the other issue, but do we want to try putting this:

txt2img_gallery img, #img2img_gallery img {
object-fit: scale-down;
image-rendering: pixelated;
image-rendering: optimizespeed;
}

At the end of your style.css and see if there's any performance improvement? There will be a slight image downgrade (outside the fullscreen preview) though.

— Reply to this email directly, view it on GitHub https://github.com/AUTOMATIC1111/stable-diffusion-webui/issues/879#issuecomment-1260009269, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACNQJ4PL6W4HSMN7SDTXFLLWANJ5VANCNFSM6AAAAAAQTLN3KU . You are receiving this because you modified the open/close state.Message ID: @.*** com>

DeepChallengerVR commented 2 years ago

I mentioned in the other issue, but do we want to try putting this:
#txt2img_gallery img, #img2img_gallery img {
    object-fit: scale-down;
    image-rendering: pixelated;
    image-rendering: optimizespeed;
}
At the end of your style.css and see if there's any performance improvement? There will be a slight image downgrade (outside the fullscreen preview) though.

Above fix did not work or make a perceived difference to me. App is very slow and unusable after looking at one batch.

using latest google chrome on up to date 10.5" ipad pro
applied above fix in .css file, restarted app
1 workaround is to reload the web page on ipad after 1 batch of photos. Not very practical though. This behavior indicates something going wrong on client side. Without looking at mobile dev tools I am guessing way to much ram or cache is being used. My system keyboard is slow the whole time and unusable after 1 batch. The keyboard is somewhat usable before even doing a batch so that might rule out the gallery being the main culprit.

I do not have time to solve this issue for foreseeable future unfortunately.

mezotaken commented 1 year ago

Reopen or create new issue if the problem is still present.

AUTOMATIC1111 / stable-diffusion-webui

Too much logging in javascript causes UI to be unresposive to inputs, often taking longer to enter a prompt then it takes to render #879

txt2img_gallery img, #img2img_gallery img {