WebUI unreasonably slow on mobile devices and tablets

[greyfoxone]

If you try to connect to a webui run in —listen mode on a lofal network the UI is extremely slow in its response

[HugoSega]

If you try to connect to a webui run in —listen mode on a local network the UI is extremely slow in its response

hello, can you provide how did you connect to a webui run in -listen mode?

[greyfoxone]

http://—ip of host—:—port—

On my Ipad pro 21.9 “. Safari Browser. Same behavior in chrome browser.

The slowdown occurs after a picture generation, than going through the pictures and pressing one of the “send to” options.

[losmurfs]

This is a duplicate of #879, although #879 is probably full of erroneous speculation on my part

[greyfoxone]

It is definitely a client side problem that accumulates with more usages of the gallery.

[dfaker]

I think this is mostly related to the gallery actually being full of full resolution copies of the images just scaled down on the client.
One thing you might try is adding:

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

at the end of your local style.css, It'll need an application restart to apply.

There will be a reduction in image quality outside of the full screen previews, but it could also improve performance.

[DeepChallengerVR]

I think this is mostly related to the gallery actually being full of full resolution copies of the images just scaled down on the client. One thing you might try is adding:

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

at the end of your local style.css, It'll need an application restart to apply.

There will be a reduction in image quality outside of the full screen previews, but it could also improve performance.

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.

P.S. I come from world of react web apps. I'm not familiar with this app yet.

[19wolf]

I'm having this issue on Safari on MacOS 12.5.1, no issue with Chrome though

[losmurfs]

I wonder if gradio's use of await tick() on keypress/keyup/input etc could be the issue. If I'm not mistaken, tick() is supposed to wait for the page to "repaint" that is to say all changes to DOM to actually finish being applied, both visually and in the document model. I'm wondering if iOS WebKit just slows down the repaint rate over time based on the time since page load thinking that they don't want all the invisible tabs hogging all of the cpu cycles when no one is even using it any more, but instead of waiting for the page to not be visible they figure as a page ages the user will interact with it less. They repaint the element that the user is interacting with with every interaction, but tick() doesn't return because it is waiting for the whole DOM update to fire off and return and so when you are trying to edit your prompt, that textarea IS repainting with each keypress but your keypress is not being added to the textarea because it is held up by handle_keypress function in gradio or one of the other functions blocked by await tick().

[ainguanzo]

Also getting this slowdown on every single iOS browser I've tried (Safari, Chrome, Firefox, Edge)

[dfaker]

Okay, another option, actually make them smaller on the client side, should narrow down if it's the huge images in tiny buttons or the actual text floating around in the dom (goes in the javascript folder):

https://gist.github.com/dfaker/89a537a245cf0444c1a3aee1bf2d2a41

Will break the size after back and forth buttons in the fullscreen lightbox, but there's an alternative source for that if this has legs.

I'm afraid I can only test on android, with a batch of 16 1088x1088 there's a delay to download the images, but once they land and are scaled down it's all very smooth.