1213967 - Compositor does not always do an immediate composite when resuming

Status: RESOLVED INVALID

(Core :: Graphics, defect)

Description

[James Willcox (:snorp) ([e-mail]) (he/him)]

Usually when we are calling CompositorParent::ResumeComposition, we want a compositing pass to happen right away. It doesn't look like that occurs, currently. We only tell the scheduler to do its thing again.

Comment 1

[James Willcox (:snorp) ([e-mail]) (he/him)]

Attachment: Invalidate and schedule a composite when resuming compositing

Comment 2

[Kartikaya Gupta (email:[e-mail])]

What sort of problem is this causing? i.e. what's the user-visible effect? Is this for iOS?

Comment 3

[James Willcox (:snorp) ([e-mail]) (he/him)]

(In reply to Kartikaya Gupta (email:[e-mail]) from comment #2)
> What sort of problem is this causing? i.e. what's the user-visible effect?
> Is this for iOS?

I noticed it on iOS when rotating the screen. I'm doing more or less the same thing we do on Android there -- resume and resize the compositor. The compositor was not actually painting a frame, though. I think this could happen on Android too, but haven't seen it for some reason (Java LayerRenderer somehow preventing it?). The code as-is definitely seems wrong to me for the way we use it.

Comment 4

[Kartikaya Gupta (email:[e-mail])]

I think on Android we trigger a recomposition from Java for the cases we care about. I'm not really sure we want to do this in general; a safer approach might be to call ScheduleRenderOnCompositorThread from the ios widget code wherever you're calling ResumeComposition. I don't have a strong opinion on this though - if you think this is better that's fine but BenWa then would be a better reviewer.

Comment 5

[Benoit Girard (:BenWa)]

I agree with kats. I don't think this is the right fix. But I can see why this would help the problem.

If we're rotating the screen this should trigger a full invalidation itself. So the invalidation call right there shouldn't be required.

The way screen rotation used to work on Android last I looked is on certain Android version during certain OS callback related to screen rotation we would have to block until the compositor outputted a frame. Similarly on OSX we force the composition during resize events, unlikely windows, which lets us not tear during resizing. So blocking on a composite is a reasonable thing to do during a rotation events if iOS wants the frame to be swapped by then, I just don't think it should be done implicitly from the resume.

Feel free to convince me if you disagree.

Comment 6

[James Willcox (:snorp) ([e-mail]) (he/him)]

I actually don't see any problem now without this patch applied, and the reasoning from Kats and BenWa is sound, so I'm going to close this.