When collecting profiler screenshots on the basic compositor, newly opened windows will have a few blank frames
Categories
(Core :: Graphics: Layers, defect, P3)
Tracking
()
People
(Reporter: barret, Assigned: mstange)
References
Details
Attachments
(2 files)
STR:
- Turn on basic compositing
- Start recording a profile with screenshots with the profiler add-on via the hotkey (ctrl+shift+1).
- Open the profiler add-on popup and collect the recording.
The resulting profile will have some initial blank frames for the profiler add-on's window.
This can also be reproduced by triggering the awesomebar to show its dropdown window while profiling before step 3.
Expected results:
The profile should not have blank frames for the pop-up windows.
Updated•5 years ago
|
Assignee | ||
Comment 1•5 years ago
|
||
I found the bug: We capture screenshots before we call EndFrame, but mFullWindowRenderTarget is only updated in EndFrame. So we capture frames that are always one frame in the past.
There's also another bug on platforms that use BufferMode::BUFFER_NONE
, where parts of screenshots get cleared and not re-drawn. That's because the clearing isn't clipped to the invalid region. But the clearing is unnecessary anyway.
Assignee | ||
Comment 2•5 years ago
|
||
These areas only need to be cleared in rt->mDrawTarget. Once the invalid area gets
copied over to mFullWindowRenderTarget, any cleared pixels will be copied over and
clear those pixels in mFullWindowRenderTarget.
This clear wasn't only necessary, it also sometimes cleared to much, because the
clip to the invalid region that the caller sets does not apply to this DrawTarget.
Assignee | ||
Comment 3•5 years ago
|
||
In the past, mFullWindowRenderTarget was updated in EndFrame, so the captured
screenshots (which were captured before EndFrame) were always one frame behind.
This affected both profiler screenshots and window recording screenshots.
This also fixes a bug with the destination offset in the call to
mFullWindowRenderTarget->mDrawTarget->CopySurface(): In the case where mTarget
was non-null, those calls would use mTargetBounds.TopLeft() as the destination
offset, which is very much unrelated to anything in mFullWindowRenderTarget.
Now the destination offset for mFullWindowRenderTarget is always zero -
mFullWindowRenderTarget->mDrawTarget's device space is the same as window space.
This patch also moves the creation of mFullWindowRenderTarget down to where we
have mRenderTarget->mDrawTarget, so that we can create a DrawTarget of a type
that can efficiently copy from mRenderTarget->mDrawTarget. I think this is
important on Windows where mRenderTarget->mDrawTarget will be the Cairo/pixman
re-wrapped DrawTarget and mDrawTarget is some kind of Windows/GDI DrawTarget.
Depends on D41612
Pushed by mstange@themasta.com: https://hg.mozilla.org/integration/autoland/rev/759f7dabeddf Stop clearing mFullWindowRenderTarget. r=mattwoodrow https://hg.mozilla.org/integration/autoland/rev/77c8de59e66a Update BasicCompositor's mFullWindowRenderTarget before we capture the screenshot for the current frame. r=mattwoodrow
Comment 5•5 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/759f7dabeddf
https://hg.mozilla.org/mozilla-central/rev/77c8de59e66a
Comment 6•5 years ago
|
||
Since the status are different for nightly and release, what's the status for beta?
For more information, please visit auto_nag documentation.
Updated•5 years ago
|
Updated•5 years ago
|
Description
•