WR compositor co-existing with non-WR compositor

[Kartikaya Gupta]

Right now in QR builds you can open two browser windows
simultaneously, one of which is rendered using WR and the other using
the regular gecko compositor. While this works, it relies on the fact
that lots of code behaves the same regardless of which compositor in
use. In particular, PImageBridge is a top-level protocol that works
basically the same regardless of whether you're using a
PWebRenderBridge or a PLayerTransaction for compositing.

This is causing a problem in bugs 1336021/1336041, where we want to
change the behaviour of ImageBridgeParent in the WR case but not
otherwise. The way I see it, we have three options:

1) Determine on a per-image (or per-compositable) basis whether or not
it will be rendered with WR. That information will be passed over
PImageBridge so that ImageBridgeParent can do the right thing.
2) Create two instances of ImageBridgeChild per process (it's
currently a per-process singleton) - one for WR and one for gecko, and
use the appropriate one.
3) Throw out the notion that we can mix compositors, and assume that
either all compositors will be WR or none of them will be WR, based on
a pref on startup.

Both option 1 and 2 have the disadvantage that we have to track down
all the different codepaths that use PImageBridge (and possibly other
similar top-level protocols) and make sure they know if they are being
composited with WR or not. That's the path I was going down but it
seems like it's a lot more work than I originally anticipated.

The alternative, option 3, is looking more appealing, but I'm not sure
if there are legitimate use cases we will want in the final release
where we want to fall back to the regular gecko compositor *in some
places* while keeping WR running in other places. Printing is the
first one that comes to mind, as I don't know if we fully resolved how
that will be handled.

Does anybody have thoughts on this? I'm not sure if I did a good job
explaining the problem, so please ask if this is unclear or is
confusing.

Cheers,
kats

[David Anderson]

PImageBridge also doesn't have anything analogous to PLayerTransaction, so it never knows what compositor instance it's going to be aimed at.

Mixing compositor backends should be extremely rare. The only way it can happen now (AFAIK) is if we fail to create some driver resources when we start a new compositor, and have to fallback to software. When that happens we don't bother to downgrade all the existing accelerated compositors.

-David

_______________________________________________
dev-tech-gfx mailing list
dev-te...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-gfx

[Sotaro Ikeda]

I also prefer to avoid mixing ClientLayerManger and WebRenderLayerManager. It makes things very difficult to support a Tab move between 2 Windows.

Sotaro

[Nicolas Silva]

Note that there's two levels of mixing WR and non-WR compositors: I think that it makes sense to be able to have some widgets use non-wr compositors (tooltips, and such), while web content and main widgets get WebRender, just like we currently disable acceleration for certain types of widgets on some platforms. Having the possibility to switch web content to and from WebRender looks a lot more challenging. The video pipeline doesn't know much about what consumes its output (for example we'll put all video frames into shmems as early as possible without the knowledge that the video frame is actually shared with the compositor, it could be only consumed a canvas or something else on the content process in which case we don't need to use shared memory but at the time of allocating the frame we don't know that. So even if we made added logic to the ImageBridge to be able to differentiate between WR and non-WR, we'd probably still have to fix things in the media pipeline. Sotaro's concern about moving tabs is also a big issue, and I believe it isn't tested (or not well tested at least).

We could still have the possibility to toggle WR on and off for all windows at once by invalidating/resetting everything just like when we recover from a driver reset I suppose.

Cheers,

Nical

[Kartikaya Gupta]

We discussed this during today's daily standup. It seems like the
printing codepath should be relatively independent and as Jeff says
"we would have to go out of our way to break it". So for now I think
the way to go is reinstate the gfx.webrender.enabled pref as a "Once"
pref read on startup. And then people can use that pref to condition
behaviour that needs to be different in WR vs not. I might make it a
gfxFeature or something instead, since we might need to disable it at
runtime because of hardware support - but the information will be
available via some static method somewhere.

[Kartikaya Gupta]

To close the loop on this: I'll be adding a gfxVars thing that people
can use to determine if webrender is enabled or not. Follow along on
bug 1337085 if interested.