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

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=220150

--- Comment #6 from Dave Blanchard <dave at grow.game> ---
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!

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20210129/26108242/attachment-0001.htm>