Visual glitch when maximizing

NEW
Unassigned

Status

()

P3
normal
a year ago
11 months ago

People

(Reporter: rodrigo.mcunha, Unassigned)

Tracking

({regression})

56 Branch
regression
Points:
---

Firefox Tracking Flags

(firefox57 fix-optional)

Details

(Whiteboard: [gfx-noted])

Attachments

(1 attachment)

(Reporter)

Description

a year ago
Created attachment 8882520 [details]
about:support

Video: https://zippy.gfycat.com/GlumNiceKatydid.webm

Not 100% sure, but I think it started with yesterday's Nightly 56.0a1 (20170629030206) on Windows 10.
Looks like we just don't draw, so we see the content behind.

I see this going back into May 2016: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=a884b96685aa13b65601feddb24e5f85ba861561&tochange=c4449eab07d39e20ea315603f1b1863eeed7dcfe
Whiteboard: [gfx-noted]
https://dxr.mozilla.org/mozilla-central/source/widget/windows/nsWindowGfx.cpp#224, or the equivalent in the patch in comment 3 is where it goes south.  We had inside the "if":

    mCompositorBridgeParent->ScheduleRenderOnCompositorThread();
    clientLayerManager->Composite();

and changed it to:

    clientLayerManager->Composite();

In the GPU compositor world, this is now:

    GetLayerManager()->ScheduleComposite();
David, with compositor bridge parent now being in a different process (potentially) is there a way to cause the equivalent of "CompositorBridgeParent::ScheduleRenderOnCompositorThread" from the nsWindow::OnPaint?  I want to try to see if that removes this regression, before deciding what the tradeoffs are and if we should fix it.
Flags: needinfo?(dvander)
(In reply to Milan Sreckovic [:milan] from comment #5)
> David, with compositor bridge parent now being in a different process
> (potentially) is there a way to cause the equivalent of
> "CompositorBridgeParent::ScheduleRenderOnCompositorThread" from the
> nsWindow::OnPaint?  I want to try to see if that removes this regression,
> before deciding what the tradeoffs are and if we should fix it.

ScheduleRenderOnCompositorThread posts a task to the compositor thread, which then schedules a composition for the next vsync. In theory ScheduleComposite does the exact same thing, except it goes over IPC instead [1][2]. That is a change in timing though, since messages over threads will get processed faster.

You could disable the GPU process, and then call ScheduleRenderOnCompositorThread as before. The widget has a mCompositorSession, which has a GetCompositorBridgeChild() method.

[1] http://searchfox.org/mozilla-central/source/gfx/layers/ipc/ShadowLayers.cpp#910
[2] http://searchfox.org/mozilla-central/rev/f1472e5b57fea8d4a7bbdd81c44e46958fe3c1ce/gfx/layers/ipc/CompositorBridgeParent.cpp#1274
Flags: needinfo?(dvander)
I'll give that a try, but I imagine it would take care of the problem, given that this regression precedes the GPU process work.  If there are performance implications though, I'd probably just wontfix this bug - the user just happens to see what's behind, but it isn't like we're leaking that information *to* Firefox.
FWIW I see the same thing when I do this with other Windows apps.
(Reporter)

Comment 9

a year ago
Me too, tested with Store, Mail and Groove Music on Windows 10.
(Reporter)

Comment 10

a year ago
For some reason I'm not able to reproduce this anymore since the latest 2 Nightlies (maybe even more, but these are the ones I tested)...
I still see it on 20170915100121
Has Regression Range: --- → yes
Has STR: --- → yes
status-firefox57: --- → fix-optional
Keywords: regression
You need to log in before you can comment on or make changes to this bug.