Bug 167605 – [GTK] Environment variables for enabling/disabling AC mode should take precedence over the API.

• Component: WebKitGTK
• Status: RESOLVED FIXED

[Carlos Alberto Lopez Perez]

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

[Carlos Garcia Campos]

No need to convince me, it was not intentional :-)

[Carlos Garcia Campos]

Created attachment 300190 [details]
Patch

[Sergio Villar Senin]

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.

[Carlos Garcia Campos]

(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.

[Carlos Garcia Campos]

Committed r211412: <http://trac.webkit.org/changeset/211412>