Make RenderThread's mWindowInfo state management easier to understand
Categories
(Core :: Graphics: WebRender, task, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox70 | --- | fixed |
People
(Reporter: mstange, Assigned: mstange)
References
Details
Attachments
(7 files)
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review |
I was reading RenderThread.cpp and had some trouble understanding how mWindowInfo's members are managed: Which parts of it belong to the same frame, whether the rendering count can become > 1, what exactly the role of the doc frame counting is, etc.
I've found some code modifications that should make things easier to understand.
Assignee | ||
Comment 1•5 years ago
|
||
Assignee | ||
Comment 2•5 years ago
|
||
IncRenderingFrame only had one caller. Inlining it into HandleFrame makes it clearer
how the values in mWindowInfos are mutated and in what order calls happen.
This also renames HandleFrame to HandleFrameOneDoc, because we're expecting one call
per document before we actually trigger the render.
Depends on D40370
Assignee | ||
Comment 3•5 years ago
|
||
Depends on D40371
Assignee | ||
Comment 4•5 years ago
|
||
The only place that increments mRenderingCount, HandleFrameOneDoc, also synchronously calls FrameRenderingComplete
at the end of the function, which decrements mRenderingCount again. So it can never grow beyond 1.
Depends on D40372
Assignee | ||
Comment 5•5 years ago
|
||
This makes it clear that these belong to a single frame and makes some assumptions explicit.
For example, in the old code, mDocFrameCounts.size() was the same as mPendingFrames.size()
when a pending frame was added, but then the sizes differed during rendering because a frame's
mDocFrameCount would be popped at the beginning of rendering while mPendingFrames would be
popped at the end of rendering.
This modification also makes some clearing of values unnecessary. A new frame always starts out
with cleared values for mDocFramesSeen and mFrameNeedsRender.
This patch also combines the two locks in HandleFrameOneDoc.
Depends on D40373
Assignee | ||
Comment 6•5 years ago
|
||
Depends on D40374
Assignee | ||
Comment 7•5 years ago
|
||
Depends on D40375
Comment 8•5 years ago
•
|
||
Thanks for simplifying this code!
Pushed by mstange@themasta.com: https://hg.mozilla.org/integration/autoland/rev/61b89c3a2aaf Combine pending frame info in RenderThread's WindowInfo. r=nical https://hg.mozilla.org/integration/autoland/rev/e04baaedbcec Inline IncRenderingFrameCount into HandleFrame. r=sotaro https://hg.mozilla.org/integration/autoland/rev/4e9fed7a845a Remove mPendingCount in favor of an accessor. r=nical https://hg.mozilla.org/integration/autoland/rev/acb46795e741 Replace mRenderingCount with a boolean, to make it clear that we are only ever rendering at most one frame. r=nical https://hg.mozilla.org/integration/autoland/rev/c393a002b81a Fold mRender, mDocFramesSeen and mDocFrameCounts into PendingFrameInfo. r=nical https://hg.mozilla.org/integration/autoland/rev/378d13e14823 Inline FrameRenderingComplete into HandleFrameOneDoc. r=nical https://hg.mozilla.org/integration/autoland/rev/267e2feb994f Add some comments to WindowInfo and reorder members a little. r=nical
Comment 10•5 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/61b89c3a2aaf
https://hg.mozilla.org/mozilla-central/rev/e04baaedbcec
https://hg.mozilla.org/mozilla-central/rev/4e9fed7a845a
https://hg.mozilla.org/mozilla-central/rev/acb46795e741
https://hg.mozilla.org/mozilla-central/rev/c393a002b81a
https://hg.mozilla.org/mozilla-central/rev/378d13e14823
https://hg.mozilla.org/mozilla-central/rev/267e2feb994f
Description
•