1211109 - Remove the static LayersBackend in CompositorParent

Status: RESOLVED FIXED

(Core :: Graphics: Layers, defect)

Description

[David Anderson [:dvander] - inactive, e-mail if emergency]

This thing is just trouble. The compositor can change for any number of reasons, so either we have to enforce that it can't, or just accept that it can and support it. Anyone interacting with the compositor should know what kind of compositor they'll have.

In practice the only transitions we make are D3D11 -> Basic and back, if for example a D3D11 call transiently fails or if a TDR occurs. We should still not be mixing D3D9/D3D11 or anything crazy like that.

Comment 1

[David Anderson [:dvander] - inactive, e-mail if emergency]

Attachment: part 1, add logging to CompositorD3D11

Motivation for this is that CompositorD3D11::Initialize seems to have a non-zero probability of failing. If that does happen it'd be nice to know exactly why it failed.

Comment 2

[David Anderson [:dvander] - inactive, e-mail if emergency]

Attachment: part 2, remove CompositorParent::sBackend

Most of this is forwarding a new LayersBackend parameter around anywhere we create a Texture in IPDL, since ImageBridgeParent is not 1:1 with CompositorParents.

I would like to have removed ISurfaceAllocator::GetCompositorBackendType too. It looks possible, but TextureClient::CreateForDrawing consumers would need to know a bit more. For now I just commented that GetCompositorBackendType is intended for TextureClient::CreateForDrawing.

Comment 3

[David Anderson [:dvander] - inactive, e-mail if emergency]

Attachment: part 3, remove an NS_ASSERTION

This removes the thebes assertion that the compositor doesn't change, and replaces it with a critical note. We now also only notify thebes of a compositor change for top-level windows.

Comment 4

[David Anderson [:dvander] - inactive, e-mail if emergency]

Attachment: part 4, remove ISurfaceAllocator::GetCompositorBackendType

It's illegal to call this for anything other than CompositableForwarder, so we may as well remove it and have consumers take in a CompositableForwarder instead.

(If this results in something unintentional, I can change affected code to pass around a LayersBackend instead.)

Comment 5

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/6de70cad7848
https://hg.mozilla.org/integration/mozilla-inbound/rev/34e69198f018
https://hg.mozilla.org/integration/mozilla-inbound/rev/f6dfce68d9e6
https://hg.mozilla.org/integration/mozilla-inbound/rev/13badd64d40f

Comment 6

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/6de70cad7848
https://hg.mozilla.org/mozilla-central/rev/34e69198f018
https://hg.mozilla.org/mozilla-central/rev/f6dfce68d9e6
https://hg.mozilla.org/mozilla-central/rev/13badd64d40f