1333329 - Fix painting during device reset

Status: RESOLVED FIXED

(Core :: Graphics: Layers, defect)

Description

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

This came out of bug 1160157 and bug 1322741. The problem is this:
 1. Parent process triggers a device reset on window A.
 2. Compositor sends new TextureFactoryIdentifiers to tabs 1, 2, and 3.
 3. Message for tab 1 arrives. Reset content device, flush layers.
 4. Message for tab 2 arrives. Flush layers.
 5. Tab 3 attempts to paint; has stale devices.
 6. Message for tab 3 arrives. Flush layers.

Since the messages to update the TextureFactoryIdentifier aren't atomic, we can paint in between handling the device reset.

To fix this, we'd have to first reset all of the compositors for all windows, then send a single message per content process issuing a device reset and asking all TabChildren to request a new TextureFactoryIdentifier synchronously.

A simpler option might be to just fix ClientLayerManager so that it does not paint if it knows about a pending reset.

Note: None of this applies to UI layers since we handle them differently.

Comment 1

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

Attachment: part 1, simplify update acks

The compositor uses a counter to see if the number of device reset acknowledgements is balanced. Instead, we can just compare it to the most recent sequence number.

Comment 2

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

Attachment: part 2, rm the device counter

Remove the device counter mechanism. It doesn't really do anything. The parent always resets atomically, and this doesn't stop the child from painting again with a bad TextureFactoryIdentifier.

Comment 3

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

Attachment: part 3, fix the bug

This caches the most recent device reset sequence number in each ClientLayerManager. CLMs then refuse to paint if the sequence number doesn't match. It can only be updated by updating the TextureFactoryIdentifier, which we assume was preceded by invalidating layers.

For this to work, we're relying on the fact that all windows in the UI are reset, and for each one, all attached PBrowsers are also reset. That's true except for basic compositors - we never reset them, so there's a special case. (Maybe it'd be better to just remove all that special casing...)

Comment 4

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

Attachment: part 4, fix think-o

This fixes a bug in OnRenderingDeviceReset. If for some reason the widget shouldn't use acceleration, but does anyway, we don't treat that as a reset.

Comment 5

[Ryan Hunt [:rhunt] (on leave until early May)]

These look great. Thanks David!

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/bb5a00c7d799
Use a simpler mechanism for tracking which ref layers need device resets. (bug 1333329 part 1, r=rhunt)
https://hg.mozilla.org/integration/mozilla-inbound/rev/1b4b15be0453
Remove the device counter mechanism from gfxPlatform. (bug 1333329 part 2, r=rhunt)
https://hg.mozilla.org/integration/mozilla-inbound/rev/4da258d42dee
Ignore paints when a content device reset has not yet been acknowledged. (bug 1333329 part 3, r=rhunt)
https://hg.mozilla.org/integration/mozilla-inbound/rev/f603c9fd66d4
Fix bogus check in OnRenderingDeviceReset. (bug 1333329 part 4, r=rhunt)

Comment 7

[Phil Ringnalda (:philor)]

https://hg.mozilla.org/mozilla-central/rev/bb5a00c7d799
https://hg.mozilla.org/mozilla-central/rev/1b4b15be0453
https://hg.mozilla.org/mozilla-central/rev/4da258d42dee
https://hg.mozilla.org/mozilla-central/rev/f603c9fd66d4