1653679 - Preparatory patches for bug 1578042 (counting dropped frames more accurately)

Status: RESOLVED FIXED

(Core :: Graphics, task)

Description

[Markus Stange [:mstange]]

In this bug I want to land patches from bug 1578042 that can land on their own without breaking anything. The rest of the patches in bug 1578042 need some more work.

Comment 1

[Markus Stange [:mstange]]

Attachment: Bug 1653679 - Update mLastFrameID in a new method UpdateCompositedFrame. r=jya

Comment 2

[Markus Stange [:mstange]]

Attachment: Bug 1653679 - Move more logic into UpdateCompositedFrame. r=jya

This also makes it so that UpdateBias for non-WebRender is only called when the
video frame changes. This mirrors the recent change that we made for WebRender
in bug 1652181. Non-WebRender only calls UpdateCompositedFrame when it actually
draws the video onto the screen, so when the video is the only thing that was
updating, the new behavior is equivalent. But the new behavior makes more sense
if you have a 30fps video and a 60fps animation running on a 60fps screen at the
same time - now the bias won't be accidentally reset every other frame.

Comment 3

[Markus Stange [:mstange]]

Attachment: Bug 1653679 - Don't call UpdateCompositedFrame outside of a composition. r=jya

Correctly indicate that we're not in a composition during SetDisplayList or
during empty transactions, by making sure the composition timestamp is null
outside of a composition.

We also now return 0 rather than -1 from the first call to ChooseImageIndex
outside of a composition, so that static images (like canvases) default to
the correct initial frame. We don't call ChooseImageIndex for them again once
we composite them.
This is different from non-WebRender, which would call ChooseImageIndex on
canvas layers during every composition.

This introduces a behavior difference for static images when WebRender is enabled:
Those images will no longer update mLastFrameID, because UpdateCompositedFrame
will not be called during a composition for them.

I'm also removing a comment that seems like it's unnecessarily duplicating
information from another comment a few lines further up. That other comment is
also easier to understand.

Comment 4

[Markus Stange [:mstange]]

Attachment: Bug 1653679 - Add a CompositionOpportunityId counter. r=jya,nical

This ID is different from the IDs we already have:

• It is different from VsyncId because it doesn't skip numbers when composites
  are delayed.
• It is different from RenderedFrameId because it also increases for no-op
  composites.
• It is different from transaction IDs and epochs because it doesn't care about
  the content side, it just looks at compositing.

Comment 5

[Markus Stange [:mstange]]

Attachment: Bug 1653679 - Propagate CompositionOpportunityId to ImageComposite. r=jya

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/bec480097ff6
Update mLastFrameID in a new method UpdateCompositedFrame. r=jya,nical
https://hg.mozilla.org/integration/autoland/rev/d9989b0e83cb
Move more logic into UpdateCompositedFrame. r=jya,nical
https://hg.mozilla.org/integration/autoland/rev/05227bc2bb3d
Don't call UpdateCompositedFrame outside of a composition. r=jya,nical
https://hg.mozilla.org/integration/autoland/rev/56b78b2f8899
Add a CompositionOpportunityId counter. r=nical
https://hg.mozilla.org/integration/autoland/rev/5d7977a864c4
Propagate CompositionOpportunityId to ImageComposite. r=jya,nical

Comment 7

[Cristina Coroiu [:ccoroiu]]

https://hg.mozilla.org/mozilla-central/rev/bec480097ff6
https://hg.mozilla.org/mozilla-central/rev/d9989b0e83cb
https://hg.mozilla.org/mozilla-central/rev/05227bc2bb3d
https://hg.mozilla.org/mozilla-central/rev/56b78b2f8899
https://hg.mozilla.org/mozilla-central/rev/5d7977a864c4