With GTK4 Epiphany Technology Preview and WebKitGTK 2.37.90 (previously tested), MotionMark reports a score of 493.19. After updating Epiphany Technology Preview to use WebKitGTK 2.39.1, MotionMark reports a score of 298. In comparison, MotionMark reports a score of 218.72 for GTK3 Gnome Web with WebKitGTK 2.36.6. The tests are run separately on the same computer in maximized window mode, with no other app running in the background.
So in summary, it's still way faster than GTK 3 was, but a huge regression from previous GTK 4 MotionMark results. Would be useful to confirm that this regression was introduced by 2.39.1. You could test 2.38.2 by downgrading org.gnome.Platform and org.gnome.Epiphany.Devel to builds from, say, two days ago, following the instructions at https://github.com/flatpak/flatpak/wiki/Tips-&-Tricks#downgrading. That way we can be certain that the regression is due to 2.38.2 -> 2.39.1, and not something else that changed in the meantime, like a change in Epiphany or GTK itself. BTW you mentioned on Matrix that you suspect the regression is caused by the switch to ANGLE for WebGL. I think that is mandatory now, but if not, maybe I could temporarily disable it to allow you to take 2.39.1 benchmarks with it turned off....
The default MotionMark suite doesn't have tests leveraging WebGL, so changes in that area should not have any effect on the benchmark.
I think motionmark doesn't test WebGL, just 2D canvas, CSS and SVG content. Was threaded rendering enabled for WebKitGTK 2.37.90? Is it now disabled for WebKitGTK 2.39.1? Cause that affects CSS and SVG, and could be the reason of the increase in performance between those versions.
(In reply to Miguel Gomez from comment #3) > Was threaded rendering enabled for WebKitGTK 2.37.90? Is it now disabled for > WebKitGTK 2.39.1? Cause that affects CSS and SVG, and could be the reason of > the increase in performance between those versions. That seems like a pretty good guess. It was disabled in 256526@main which landed just before 2.39.1. But there is an environment variable override: you can use WEBKIT_NICOSIA_PAINTING_THREADS=4 to go back to the previous behavior, so you can benchmark again without needing to downgrade anything and see if that is to blame. Seems pretty likely.
(In reply to Michael Catanzaro from comment #4) > That seems like a pretty good guess. It was disabled in 256526@main which > landed just before 2.39.1. But there is an environment variable override: > you can use WEBKIT_NICOSIA_PAINTING_THREADS=4 to go back to the previous > behavior, so you can benchmark again without needing to downgrade anything > and see if that is to blame. Seems pretty likely. Note that flatpak maybe filters out environment variables? Probably need to enter the flatpak environment using 'flatpak run --command=/bin/bash org.gnome.Epiphany.Devel' before setting the environment variable, rather than try running flatpak with that environment variable set.
(In reply to Michael Catanzaro from comment #1) > So in summary, it's still way faster than GTK 3 was, but a huge regression > from previous GTK 4 MotionMark results. > > Would be useful to confirm that this regression was introduced by 2.39.1. > You could test 2.38.2 by downgrading org.gnome.Platform and > org.gnome.Epiphany.Devel to builds from, say, two days ago, following the > instructions at > https://github.com/flatpak/flatpak/wiki/Tips-&-Tricks#downgrading. That way > we can be certain that the regression is due to 2.38.2 -> 2.39.1, and not > something else that changed in the meantime, like a change in Epiphany or > GTK itself. > > BTW you mentioned on Matrix that you suspect the regression is caused by the > switch to ANGLE for WebGL. I think that is mandatory now, but if not, maybe > I could temporarily disable it to allow you to take 2.39.1 benchmarks with > it turned off.... I run the benchmark pretty much every time WebKitGTK updates, and it’s still reporting near 500 in 2.38.1/2.
Not sure if it's related, but when I run Epiphany (WebKitGTK 2.39.1) from the terminal I get 3 lines of `ERR: Display.cpp:1006 (initialize): ANGLE Display::initialize error 12289: Failed to initialize system egl`. I'll run the benchmarks with threaded rendering later.
I have run MotionMark again with WEBKIT_NICOSIA_PAINTING_THREADS=4 (Epiphany Technology Preview, WebKitGTK 2.39.1), and the score is 303.68. Not so different than with threaded rendering off.
OK, so it's not related to threaded rendering after all. I suppose something really *is* wrong with ANGLE if EGL initialization succeeded with 2.38.2 but fails with 2.39.1....
(In reply to kdwkleung from comment #7) > Not sure if it's related, but when I run Epiphany (WebKitGTK 2.39.1) from > the terminal I get 3 lines of `ERR: Display.cpp:1006 (initialize): ANGLE > Display::initialize error 12289: Failed to initialize system egl`. That error comes from ANGLE, so for some reason angle is indeed used when running motionmark, but it shouldn't.
(In reply to Carlos Garcia Campos from comment #10) > (In reply to kdwkleung from comment #7) > > Not sure if it's related, but when I run Epiphany (WebKitGTK 2.39.1) from > > the terminal I get 3 lines of `ERR: Display.cpp:1006 (initialize): ANGLE > > Display::initialize error 12289: Failed to initialize system egl`. > > That error comes from ANGLE, so for some reason angle is indeed used when > running motionmark, but it shouldn't. I don't think it appeared when using MotionMark, it appeared when I visit apple.com and reddit.com
Could you share the results of webkit://gpu?
Created attachment 463708 [details] Results of webkit://gpu This is the webkit://gpu page
Note: this issues persists as of WebKitGTK 2.39.4, which resolves an ANGLE bug causing WebGL to not be available.
Seems this can be solved by WEBKIT_NICOSIA_PAINTING_THREADS=4, which should be possible now that threaded safety has been solved and the crashes went away. I tested this env var for quite some time and seems pretty stable so far with big performance boost compared to without.
I'll add this environment variable to Epiphany Tech Preview so we can test it there for a couple weeks before changing WebKit again. https://gitlab.gnome.org/GNOME/epiphany/-/merge_requests/1307 I'd be more confident if I knew more about what the painting thread is actually doing: what libraries does it use, and why are the safe to use on a thread.
Fixed after latest Tech Preview env var change.
I just added that for testing, though. I'll remove it now. We didn't notice crashes in practice, but I'm not confident that means it's really safe to do.