After r211363 <http://trac.webkit.org/r211363> the WEBKIT_DISABLE_COMPOSITING_MODE environment variable not longer works as one should expect. Not sure if this was intentional or not. But I think we should bring back this environment variable, and make it take precedence over any API setting that the application defines. This is useful for the following use cases: * Testing if disabling AC makes a difference without having to rebuild the application to add a different API call. * Letting the user override the application acceleration hardware policy, which is useful when the user has a broken graphics drivers, and despite of that wants to use a WebKitGTK+ based application that enables AC mode by default (or that enables it ondemand). - For example, users of nvidia binary graphics drivers right now can only use Epiphany flatpaks with this environment variable. Otherwise the browser will crash when trying to enter into AC mode. And I don't expect Epiphany to disable AC. - So with this at least the user can use this environment variable at runtime to override the HW policy settings of the application And the same for the other variable WEBKIT_FORCE_COMPISITING_MODE
No need to convince me, it was not intentional :-)
Created attachment 300190 [details] Patch
I know it's already like this, but I personally find confusing from the user of the API POV, to have a set method that might work or not. I think it would be better to explicitly return the changed boolean so that we could immediately know whether or not the API call has succeeded. Apart from that, I like the idea of adding this hardware manager class.
(In reply to comment #3) > I know it's already like this, but I personally find confusing from the user > of the API POV, to have a set method that might work or not. I think it > would be better to explicitly return the changed boolean so that we could > immediately know whether or not the API call has succeeded. Yes, but still, it's very unlikely to happen, either the user set the env variables, so he/she knows what he/she is doing, or xwindow doesn't support xcomposite/xdamage (unlikely). > Apart from that, I like the idea of adding this hardware manager class.
Committed r211412: <http://trac.webkit.org/changeset/211412>