See also: bug #2061996 for RHEL 9.1

There is one known regression in Evolution, which Milan is aware of. See https://bugzilla.redhat.com/show_bug.cgi?id=2061996#c6.

This is going to require some work in GLib as well. https://github.com/WebKit/WebKit/commit/e3254ab398aeb4c95f518f2a18439e19aa653137 depends on some newer functionality of gdbus-codegen, --interface-info-body and --interface-info-header.

(In reply to Michael Catanzaro from comment #4)
> There is one known regression in Evolution, which Milan is aware of. See
> https://bugzilla.redhat.com/show_bug.cgi?id=2061996#c6.

And https://bugs.webkit.org/show_bug.cgi?id=239429 , which is even more sever, because causes crashes.

(In reply to Milan Crha from comment #6)
> And https://bugs.webkit.org/show_bug.cgi?id=239429 , which is even more
> sever, because causes crashes.

See: https://bugzilla.redhat.com/show_bug.cgi?id=2061996#c11

We can use this patch to revert back to on-demand hardware acceleration:

diff --git a/Source/WebKit/UIProcess/API/glib/WebKitSettings.cpp b/Source/WebKit/UIProcess/API/glib/WebKitSettings.cpp
index 5ab3c348f4b7..623d4adae0c2 100644
--- a/Source/WebKit/UIProcess/API/glib/WebKitSettings.cpp
+++ b/Source/WebKit/UIProcess/API/glib/WebKitSettings.cpp
@@ -1488,7 +1488,7 @@ static void webkit_settings_class_init(WebKitSettingsClass* klass)
             _("Hardware Acceleration Policy"),
             _("The policy to decide how to enable and disable hardware acceleration"),
             WEBKIT_TYPE_HARDWARE_ACCELERATION_POLICY,
-            WEBKIT_HARDWARE_ACCELERATION_POLICY_ALWAYS,
+            WEBKIT_HARDWARE_ACCELERATION_POLICY_ON_DEMAND,
             readWriteConstructParamFlags);
 
     /**
diff --git a/Tools/TestWebKitAPI/Tests/WebKitGLib/TestWebKitSettings.cpp b/Tools/TestWebKitAPI/Tests/WebKitGLib/TestWebKitSettings.cpp
index 00caf4886fb8..65a4623a55e5 100644
--- a/Tools/TestWebKitAPI/Tests/WebKitGLib/TestWebKitSettings.cpp
+++ b/Tools/TestWebKitAPI/Tests/WebKitGLib/TestWebKitSettings.cpp
@@ -340,14 +340,14 @@ static void testWebKitSettings(Test*, gconstpointer)
 
 #if PLATFORM(GTK)
 #if !USE(GTK4)
-    // Always is the default hardware acceleration policy.
-    g_assert_cmpuint(webkit_settings_get_hardware_acceleration_policy(settings), ==, WEBKIT_HARDWARE_ACCELERATION_POLICY_ALWAYS);
+    // Ondemand is the default hardware acceleration policy.
+    g_assert_cmpuint(webkit_settings_get_hardware_acceleration_policy(settings), ==, WEBKIT_HARDWARE_ACCELERATION_POLICY_ON_DEMAND);
     webkit_settings_set_hardware_acceleration_policy(settings, WEBKIT_HARDWARE_ACCELERATION_POLICY_NEVER);
     g_assert_cmpuint(webkit_settings_get_hardware_acceleration_policy(settings), ==, WEBKIT_HARDWARE_ACCELERATION_POLICY_NEVER);
-    webkit_settings_set_hardware_acceleration_policy(settings, WEBKIT_HARDWARE_ACCELERATION_POLICY_ON_DEMAND);
-    g_assert_cmpuint(webkit_settings_get_hardware_acceleration_policy(settings), ==, WEBKIT_HARDWARE_ACCELERATION_POLICY_ON_DEMAND);
     webkit_settings_set_hardware_acceleration_policy(settings, WEBKIT_HARDWARE_ACCELERATION_POLICY_ALWAYS);
     g_assert_cmpuint(webkit_settings_get_hardware_acceleration_policy(settings), ==, WEBKIT_HARDWARE_ACCELERATION_POLICY_ALWAYS);
+    webkit_settings_set_hardware_acceleration_policy(settings, WEBKIT_HARDWARE_ACCELERATION_POLICY_ON_DEMAND);
+    g_assert_cmpuint(webkit_settings_get_hardware_acceleration_policy(settings), ==, WEBKIT_HARDWARE_ACCELERATION_POLICY_ON_DEMAND);
 #endif
 
     // Back-forward navigation gesture is disabled by default

I was about to apply it to our RHEL 8 package, because Milan prefers that we be cautious and avoid exposing problems caused by broken hardware acceleration. But now I'm having second thoughts. On-demand hardware acceleration has been a source of historical bugs, and upstream will no longer be testing this anymore now that it's no longer enabled by default. It will probably work fine for now, but I'm worried it will break in the future.

IMO the risk of regressions is high either way. If we use on-demand policy when no other distros are using it, it would be easy to fail to notice that it's broken. If we use the always policy, then it will likely be broken for particular users and not for others, depending on hardware.

For now, it's probably safest to expect hardware acceleration to work properly. At least when hardware acceleration is always on, you'll notice immediately if it's broken on your hardware. When it's on-demand, then it's much harder to notice whether we've shipped something that's broken or not. We will likely get some bug reports due to this, but at least they should be upstream bugs if we stay closer to upstream.

So for now, I will not apply this patch to our package. But it's not a final decision. We can change our minds.

(In reply to Milan Crha from comment #6)
> And https://bugs.webkit.org/show_bug.cgi?id=239429 , which is even more
> sever, because causes crashes.

Another consideration: so far I've seen reports of trouble from NixOS and Ubuntu, but none from Fedora users. (This could just be luck, though....)

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Moderate: webkit2gtk3 security and bug fix update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2022:7704