1087347 - Make it possible to change the compositing backend at runtime

Status: RESOLVED WORKSFORME

(Core :: Graphics: Layers, defect)

Description

[Nicolas Silva [:nical]]

The goal is to avoid being stuck with an unusable browser because of a driver bug.

Not as easy as it sounds, but in some cases we could detect errors and fallback automatically to another backend instead of relying on receiving user reports of unusable browser and deploying a blacklist.

This means we'd need to tell the content-side to use a different drawing backend (using D2D without D3D9 is probably not a good idea, and not a config we want to support), rebuild the layer tree, make sure that video frames specific to a certain backend aren't being produced asynchronously, etc.

Another possibility could be to remember that we went above a certain threshold of unrecoverable compositing errors and fallback to another backend next time firefox starts. The risk is to become stuck with a backend because some specific web content (a webgl demo or whatnot) did something we didn't think about and triggered enough errors to make us fallback indefinitely (maybe try again at each release?).

Comment 1

[Benoit Jacob [:bjacob] (mostly away)]

In the case of the bug we're currently dealing with, we seem to be able to test ahead of time if d3d11 resource sharing works on a given system, so we can take that into account in the initial decision of which compositor backend to use.

But what you describe would probably be very useful for other bugs.

Comment 2

[Milan Sreckovic [:milan] (needinfo for best results)]

I'd be happy enough to do this at the start up, once, and not worry about the scenario where we start failing half way through the session (e.g., people update the driver during the execution of Firefox), but I understand that would mean more "testing" of the kind mentioned in comment 1.

Comment 3

[Matt Woodrow (:mattwoodrow)]

(In reply to Benoit Jacob [:bjacob] from comment #1)
> In the case of the bug we're currently dealing with, we seem to be able to
> test ahead of time if d3d11 resource sharing works on a given system, so we
> can take that into account in the initial decision of which compositor
> backend to use.
> 
> But what you describe would probably be very useful for other bugs.

I think for the general case, we'd be best served by using the same infrastructure as we do for reftesting. Do a readback of the final frame we push to screen, and then analyze it to make sure it's valid/sane.

Doing that would protect us from missing bugs that happen in our real compositor code, but not in the minimal test case that we created for a different bug.

One nice idea would be to detect when we start the browser for the first time (and when drivers have changed), and then run a minimal set of reftests to confirm that things work as expected.