Bug 1521964 Comment 37 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

(In reply to Mike Conley (:mconley) (:⚙️) from comment #31)

> Hi sotaro,
> 
> So I think I've got something almost landable here (modulo the test stuff, and this negative leak I'm getting in automation...), but I've noticed a small bug that I can reproduce reliably manually, but can't seem to write a decent automated test for.
> 
> I'm noticing that in certain situations, even though frames are being sent from the VideoSink to the secondary VideoFrameContainer, they do not appear on screen until a main thread paint occurs (any kind of main thread paint will do, it seems). Do you know how I'd start to debug that?

Main thread paint is necessary to update display list and layer transaction of video. It is triggered by VideoFrameContainer::InvalidateWithFlags(). It calls HTMLMediaElement::Invalidate().

The InvalidateWithFlags() is called from VideoFrameContainer::Invalidate() and MediaDecoder::InvalidateWithFlags().
(In reply to Mike Conley (:mconley) (:⚙️) from comment #31)

> Hi sotaro,
> 
> So I think I've got something almost landable here (modulo the test stuff, and this negative leak I'm getting in automation...), but I've noticed a small bug that I can reproduce reliably manually, but can't seem to write a decent automated test for.
> 
> I'm noticing that in certain situations, even though frames are being sent from the VideoSink to the secondary VideoFrameContainer, they do not appear on screen until a main thread paint occurs (any kind of main thread paint will do, it seems). Do you know how I'd start to debug that?

Main thread paint is necessary to update display list and layer transaction of video. It is triggered by VideoFrameContainer::InvalidateWithFlags(). It calls HTMLMediaElement::Invalidate().

The InvalidateWithFlags() is called from VideoFrameContainer::Invalidate() and MediaDecoder::InvalidateWithFlags().

For async image container, ImageClientBridge is created on MainThread.
(In reply to Mike Conley (:mconley) (:⚙️) from comment #31)

> Hi sotaro,
> 
> So I think I've got something almost landable here (modulo the test stuff, and this negative leak I'm getting in automation...), but I've noticed a small bug that I can reproduce reliably manually, but can't seem to write a decent automated test for.
> 
> I'm noticing that in certain situations, even though frames are being sent from the VideoSink to the secondary VideoFrameContainer, they do not appear on screen until a main thread paint occurs (any kind of main thread paint will do, it seems). Do you know how I'd start to debug that?

Main thread paint is necessary to update display list and layer transaction of video. It is triggered by VideoFrameContainer::InvalidateWithFlags(). It calls HTMLMediaElement::Invalidate().

The InvalidateWithFlags() is called from VideoFrameContainer::Invalidate() and MediaDecoder::InvalidateWithFlags().

For async image container, ClientImageLayer and ImageClientBridge are created on MainThread.

Back to Bug 1521964 Comment 37