Closed Bug 1545262 Opened 1 year ago Closed 1 year ago

When collecting profiler screenshots on the basic compositor, newly opened windows will have a few blank frames

Categories

(Core :: Graphics: Layers, defect, P3)

68 Branch
defect

Tracking

()

RESOLVED FIXED
mozilla70
Tracking Status
firefox68 --- wontfix
firefox69 --- wontfix
firefox70 --- fixed

People

(Reporter: barret, Assigned: mstange)

References

Details

Attachments

(2 files)

STR:

  1. Turn on basic compositing
  2. Start recording a profile with screenshots with the profiler add-on via the hotkey (ctrl+shift+1).
  3. 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.

Priority: -- → P3

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: nobody → mstange
Status: NEW → ASSIGNED

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.

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
Status: ASSIGNED → RESOLVED
Closed: 1 year ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla70

Since the status are different for nightly and release, what's the status for beta?
For more information, please visit auto_nag documentation.

QA Whiteboard: [qa-70b-p2]
You need to log in before you can comment on or make changes to this bug.