The website I'm using for this is a static one with pretty simple CSS: fortintam.com Here's how it looks like comparing Epiphany's Technology Preview (also affects the stable version) with Firefox: https://youtube.com/watch?v=FUk-1t5AxV0 I'm running Fedora 33 with open source AMD Radeon (radeonsi) Pitcairn graphics in the GNOME 3.38 xorg session.
Just for the record if anyone is seeing this: I've tested this again with Epiphany 42 in a Fedora 36 machine running with AMD Radeon APU graphics. Since Epiphany 42 reportedly force-turns-on accelerated compositing etc., I was hoping it might make a difference; it does not. The sluggishness remains even for scrolling this simple website, even on a GNOME Wayland session. Bug #215045 also remains affected in the same way (but worse, since it's dealing with much heavier websites).
This only happens with async scrolling, when using ondemand policy in GTK port or disabling AC mode makes it work fine. The problem seems to be the background image that is too big and for some reason with async scrolling looks like it's painted all the time or something like that. I'll attach a reduced test case.
Created attachment 462223 [details] Reduced test case
I thought the problem was the big image causing a performance degradation, but I'm nto sure anymore. The big image jut makes the problem easily noticeable, but I think it's always there in any case. It looks like we do start scrolling the background, that then it's positioned in the fixed position again, causing the weird effect at the top.
I've identified the problem and we are now working on a solution.
Pull request: https://github.com/WebKit/WebKit/pull/5748
Committed 255959@main (1bf61e6bec18): <https://commits.webkit.org/255959@main> Reviewed commits have been landed. Closing PR #5748 and removing active labels.
I tested with the current org.gnome.Epiphany.Devel "technology preview" flatpak from gnome-nightly, and unfortunately the issue still occurs there. I am told that the fix should have been present in that version by now, so something must be missing or maybe the fix didn't work...
Created attachment 464649 [details] sysprof capture of epiphany nightly from 2023-01-24 while scrolling that page In case this can be insigthful, here's a profile done on Fedora 37 with the overpowered i7 Kaby Lake machine, on Wayland, in 4K HiDPI. Same hardware/software specs as in bug #250998.
In case this updated info is relevant: * Today, I tried with the current TP and Epiphany 44.rc from Fedora 38, and the slow scroll persists on that page, whether on my 4K+Wayland+Intel graphics test machine, or my HD+Xorg+AMD main desktop. * Out of curiosity, I grabbed Epiphany's web inspector and tried turning off various CSS properties of that page, such as: the fixed background on the body element, box shadow around #contenu, text shadows in the nav element... and it's still not smooth. That's surprising to me because I thought shadows might have been the problem.
I can no longer reproduce with Gnome Web 44.1/ WebKitGTK 2.40
I can still reproduce this with GNOME Web 44.2 / WebKitGTK 2.40.1, even on Wayland, with my desktop's open source AMD graphics.
Created attachment 466185 [details] sysprof capture of Epiphany 44.2 with triple-buffered Wayland Here's a new sysprof capture, this time with a fully up-to-date Fedora 38 + the patched version of Mutter than has triple-buffering for the best possible Wayland performance. Even under those optimal conditions, the view still lags when scrolling on that page. It seems to have something to do with pixman_image_composite32 in cairo, as a result of webkitgtk doing a lot of cairo_paint_with_alpha requests? Just guessing, as I don't really know what I'm looking at, but hopefully this updated sysprof gives you new insights.
Created attachment 466186 [details] Screenshot of the Sysprof output In this screenshot you can see the approximate area I selected on the measurements timeline, as the peak before it is certainly the app's startup and page loading.
I discovered today that one of the pages of my website in particular makes the problem 10x worse, thus much easier to reproduce on probably any machine (it happens even with my overpowered laptop with Intel Kabylake graphics on Wayland): try scrolling https://fortintam.com/en/clients/ and watch your frames drop!
Created attachment 468628 [details] sysprof 45 capture on the logos page This new sysprof capture is probably going to be much more useful, as it bundles a ton more information. This was recorded with my Intel Kabylake laptop on the GNOME 45 Wayland session on Fedora 39. I scrolled using a traditional (discrete) mouse wheel, and then using the laptop's touchpad (with two fingers).
Created attachment 468629 [details] Screenshot from sysprof 45 - flame graph
Created attachment 468630 [details] Screenshot from sysprof 45 - call graph, part 1
Created attachment 468631 [details] Screenshot from sysprof 45 - call graph, part 2
Created attachment 468632 [details] Screenshot from sysprof 45 - call graph, part 3
Created attachment 468633 [details] Screenshot from sysprof 45 - graphics stack marks
fortintam.com seems to be fixed. fortintam.com/clients seems not be fixed even with Skia.
For me, both the front page and the clients page remain "not smooth" with Epiphany Devel/TP (i.e. with Skia). It's just that the clients page exhibits the problem much more visibly.