Bug 201527 – [GTK] Substantial text entry performance regression in 2.25.x

• Status: NEW
• Component: WebKitGTK

[Michael Gratton]

Typing text into inputs and textareas on some (all?) websites is slow as molasses. The display of text and updating the position text caret is slower than I can type, which leads to a very sluggish text entry experience. This is true of all text form controls on this web site, also on gitlab.gnome.org. It may also be an issue on others.

For example, the display of text in this textarea is such that if I press and hold down a key so that repeats kicks in, new letters are inserted slower than the repeat rate, so that upon release of the key additional letters continue to be added for several seconds. This is also true of moving the text caret with the arrow keys, in that it can take several seconds for the caret to get to the desired position, which substantially slows down editing.

This is a regression from 2.24. I can reproduce it using current Epiphany.Devel Flatpak nightly with WebKit 2.25.92, also with WebKit 2.25.4 using Epiphany 3.32 from Ubuntu Eoan. The effect is less pronounced (but still present) using minibrowser.

Currently using Wayland, not tried with X11.

[Adrian Perez]

I think this may be related to bug #185248 — some other changes
introduced since 2.24.x might have made exacerbated the issue.

[Carlos Garcia Campos]

I can't reproduce it, what GTK version?

[Michael Gratton]

GTK 3.24.10 on Ubuntu Eoan, 3.24.11 from gnome-nightly

[Michael Gratton]

Oh, interesting, so I just half-screened Ephy so I could keep an eye on CPU load via System Monitor while holding down a key, and when reproducing the problem in this textarea it was performing substantially better. Maximising the window again made it much worse again. This is on a 1920x1080 screen.

So I launched the GTK Inspector to see if it's a repainting issue by enabling "Show Graphics Updates", and this also makes the problem far worse.

Then I realised I have fractional scaling enabled (125%) - and setting scaling to to either 100% or 200% also obviates the problem.

I'm not sure if any of that helps, but it seems to be a) related to painting speed and b) made far worse by fractional scaling.

[Carlos Garcia Campos]

what is fractional scaling? how can I change that?

[Michael Gratton]

`gsettings set org.gnome.mutter experimental-features "['scale-monitor-framebuffer']"`

Then open the Screen panel in Settings and choose a scale that isn't 100 or 200%.

More info: https://blog.3v1n0.net/informatica/linux/gnome-shell-fractional-scaling-in-wayland-landed/