Bug 220150 – [GTK] Initial page scroll is slow and laggy for a few seconds, after browser has been idle

• Status: RESOLVED
• Resolution: FIXED
• Component: WebKitGTK

[Dave Blanchard]

I am using WebKitGTK 2.30.4 on my own "from scratch" Linux distro, with a one-source-file browser written in C. Very basic usage of WebKit, nothing special. Everything about the browser works great, except for one rather annoying problem. If the browser has been allowed to idle for about 20-30 seconds, initial scrolling of a page will be slow and laggy. After a couple seconds of intense scrolling, it "clears up" and becomes smooth and responsive, and will remain so up indefinitely--until the browser is allowed to idle again, at which point the problem reoccurs. 

Literally every other program on this computer is blazing fast and responsive, because I have specifically built this system to be so. Chromium for example is fast and snappy. This is a Ryzen3 with 32GB of ram, an SSD, and no swap partition. So I'm pretty sure it's not the OS. Only WebKit has this problem.

In an attempt to triage this, I've recompiled WebKit with virtually everything disabled (particularly OpenGL support), with no effect. I thought it might be a problem with some thread being given too low priority, so I also tried disabling functions relating to setting thread priority, and increasing various priorities in ./Source/WTF/wtf/glib/RunLoopSourcePriority.h, with no apparent effect.

So now I turn to you, dear WebKit bugzilla, in hopes of finding a solution to this very frustrating problem. 

Hopefully this is a known issue and you might have some ideas on how to solve it. If not, I have a full suite of debugging tools available, so let me know what steps I can take to help diagnose and solve this problem. 

Here's how WebKit is configured right now. Compiler is GCC 9.3.0, on glibc 2.27, with Linux 4.18.5. Let me know if you need any more info:

cmake -DCMAKE_INSTALL_PREFIX=/usr \
      -DCMAKE_BUILD_TYPE="RelWithDebInfo" \
      -DCMAKE_CXX_FLAGS="$CXXFLAGS" \
      -DCMAKE_EXPORT_COMPILE_COMMANDS=ON \
      -DENABLE_ACCELERATED_2D_CANVAS=OFF \
      -DENABLE_ASYNC_SCROLLING=ON \
      -DENABLE_BUBBLEWRAP_SANDBOX=OFF \
      -DENABLE_DRAG_SUPPORT=ON \
      -DENABLE_GEOLOCATION=OFF \
      -DENABLE_GRAPHICS_CONTEXT_GL=OFF \
      -DENABLE_GTKDOC=OFF \
      -DENABLE_MEDIA_SOURCE=OFF \
      -DENABLE_MHTML=ON \
      -DENABLE_MINIBROWSER=OFF \
      -DENABLE_NOTIFICATIONS=OFF \
      -DENABLE_ORIENTATION_EVENTS=OFF \
      -DENABLE_SPELLCHECK=OFF \
      -DENABLE_TOUCH_EVENTS=OFF \
      -DENABLE_UNIFIED_BUILDS=ON \
      -DENABLE_VIDEO=OFF \
      -DENABLE_WEB_AUDIO=OFF \
      -DENABLE_WEBDRIVER=OFF \
      -DENABLE_WEBGL=OFF \
      -DENABLE_WEBASSEMBLY=OFF \
      -DENABLE_WEB_RTC=OFF \
      -DENABLE_X11_TARGET=ON \
      -DPORT=GTK \
      -DUSE_LIBNOTIFY=OFF \
      -DUSE_SYSTEMD=OFF ..


Thanks for any help you can provide!

[Dave Blanchard]

Forgot to mention: CXXFLAGS is set to -O2 -fuse-ld=gold -fpermissive, if that matters.

[Dave Blanchard]

Oops, also meant to mention that this is with smooth scrolling disabled.

[Dave Blanchard]

Just did some experimentation. If the browser is left idle for 23 seconds or more, the bug is triggered. 22 seconds or less, no bug. Seems to be pretty consistent!

[Radar WebKit Bug Importer]

<rdar://problem/72770042>

[Dave Blanchard]

Created attachment 418690 [details]
Video of bug

[Dave Blanchard]

I've been doing more testing. When the system is heavy load, such as when compiling with all cores at 100%, all applications remain snappy and responsive, but WebKit suffers more than ever. There is much more lagginess, and it applies not only to page scrolling but text entry, like in this text box for example. 

After a few seconds of intense activity (i.e. dragging the scrollbar up and down rapidly, or holding down the delete key in the text entry box) it will clear up fine and is quite smooth and responsive, even under heavy load. Small bursts of activity like scrolling the page a few lines, moving the cursor around in the edit box, or normal typing aren't sufficient to get out of "lag mode"; it requires major activity for several seconds. 

As reported above, when the system is relatively idle, approximately 23 seconds go by before the lagginess returns, but under load, it's much shortened to only a few seconds. As long as activity is sustained however, like continuing to keep the cursor moving, entering text, etc, the browser will remain responsive. 

My hypothesis is this has something to do with the way WebKit schedules threads, i.e. how it interacts with the kernel. Somehow it's getting deprioritized, I think. It could possibly end up being a kernel configuration issue; I can't prove that it's not, although I've spent a lot of time studying and tweaking various possibilities in the kernel config, with no success so far.

If there's anyone out there who has seen this bug and is leery about committing to what could very well be a long, frustrating debugging attempt, I understand. If a knowledgeable person who, ideally, knows something about how WebKit schedules threads, could please email me offline and just give me some general pointers on how to get started troubleshooting this, I will do what I can by myself and promise not to bother you much!

WebKit has been good to me so far; I've been expanding my little browser a bit with extra functionality, and it's super nice being able to build this thing to do exactly what I need, without all the bloat, privacy problems, etc that Chromium brings. Getting this bug fixed is a major last hurdle keeping me on that POS browser, and will likely make other people happy also, so I'm eager to figure this out. 

I attached a short video, demonstrating the problem. Having the screen recorder running seems to make "lag mode" much more difficult to escape. It's laggy for about 13-14 seconds then clears up right at the end.

Thank you and happy new year to WebKit devs!

[Carlos Garcia Campos]

If it's a matter of threads scheduling and priorities, we might try to implement Thread::QOS for Linux using pthread_setschedparam or playing with the nice value. Adri, what do you think?

[Carlos Garcia Campos]

Is this still a problem with current trunk? We already added support for real time threads.

I'm the original bug filer; had to create a new account because I lost my password, and also access to that email account. 

I just upgraded to WebKit 2.36.0 and this problem is now resolved. Browser UI is snappy and responsive. Thanks a lot!