1375349 - Add calling ScheduleComposition() in CompositorBridgeParent::RecvAdoptChild()

Status: RESOLVED FIXED

(Core :: Graphics: Layers, enhancement)

Description

[Sotaro Ikeda [:sotaro]]

RecvAdoptChild() makes a move of LayerTransactionParent from one CompositorBridgeParent to another CompositorBridgeParent.

Bug 1335335 is for adding support of WebRenderBridgeParent to RecvAdoptChild(). During working it, there was a case that client side did not repaint because that client did not receive DidComposite.

Same problem could happen also for LayerTransactionParent.

Comment 1

[Sotaro Ikeda [:sotaro]]

Attachment: patch Add calling DidComposite() in CompositorBridgeParent::RecvAdoptChild()

Comment 2

[Sotaro Ikeda [:sotaro]]

Attachment: patch - Add calling DidComposite() in CompositorBridgeParent::RecvAdoptChild()

Comment 3

[Sotaro Ikeda [:sotaro]]

Attachment: patch - Add calling DidComposite() in CompositorBridgeParent::RecvAdoptChild()

Comment 4

[Sotaro Ikeda [:sotaro]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=2f2c74d70d1fa9bcc2edf65b9abcc59787974ca7

Comment 5

[Matt Woodrow (:mattwoodrow)]

Comment on attachment 8880239 [details] [diff] [review]
patch - Add calling DidComposite() in CompositorBridgeParent::RecvAdoptChild()

Review of attachment 8880239 [details] [diff] [review]:
-----------------------------------------------------------------

I'm a bit confused about this.

DidComposite is supposed to notify the client side that we actually composited.

If the client side is blocking and waiting for a DidComposite message, where did the real one go?

Is there a race condition where we're sending the DidComposite back to the wrong ClientLayerManager?

Comment 6

[Sotaro Ikeda [:sotaro]]

Sorry, I confused with webrender case. In the case, it could not be composited with new webrender, since webrender keys are not valid in a new webrender instance.

In normal composition case, the composition could happen with a new compositor. Then a composition should be scheduled with a new compositor.

Comment 7

[Sotaro Ikeda [:sotaro]]

(In reply to Matt Woodrow (:mattwoodrow) from comment #5)
> Review of attachment 8880239 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> I'm a bit confused about this.
> 
> DidComposite is supposed to notify the client side that we actually
> composited.
> 
> If the client side is blocking and waiting for a DidComposite message, where
> did the real one go?

The real composition should happen with a new compositor. attachment 8880239 [details] [diff] [review] is not correct fix.

> Is there a race condition where we're sending the DidComposite back to the
> wrong ClientLayerManager?

There could be a race condition. Same ClientLayerManager is used to receive composition. But there is a possibility that parent side do not send DidComposite. LayerTransactionParent could be moved to a new composition before the transaction is composited on an old compositor.

Comment 8

[Sotaro Ikeda [:sotaro]]

Attachment: patch - Add calling ScheduleComposition() in CompositorBridgeParent::RecvAdoptChild()

Comment 9

[Sotaro Ikeda [:sotaro]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=3f39645000fd9af1b9d0fce3627458d4b2bc1dbb

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/5e83b520f1a0
Add calling ScheduleComposition() in CompositorBridgeParent::RecvAdoptChild() r=mattwoodrow

Comment 11

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/5e83b520f1a0