Force DWM to update cached nonclient area
Categories
(Core :: Widget: Win32, defect, P2)
Tracking
()
People
(Reporter: rkraesig, Assigned: rkraesig)
References
Details
Attachments
(4 files)
On Windows 11, DWM sometimes doesn't update it's cached client area for a window if that window's client area, but not its size, changes. This can result in bug 1763981.
(This bug is separate from bug 1763981 only to avoid spamming users CC'd there with the metadata and administrivia resulting from patches here.)
Assignee | ||
Comment 1•2 years ago
|
||
This reverts Mercurial commit ec948153333a957e3ef5302b5b0f469eda0d48a8
(introduced as part of bug 1820066) due to reports of tearing while
playing full-screen video.
Assignee | ||
Comment 2•2 years ago
|
||
Remove unused code:
- nsWindow::AutoErase() (allegedly overridable but nonvirtual function)
- nsWindow::mIsPainting (flag which is never set)
... and perform a very minor comment emendation, for clarity.
Depends on D176841
Assignee | ||
Comment 3•2 years ago
|
||
This mitigation exposed bug 1763981. Unfortunately, not applying it on
Nightly made it look like bug 1763981 was fixed in Nightly, tricking
several users and developers and making testing needlessly more
difficult even after this was discovered.
Apply the mitigation across the board, regardless of release channel.
Developers may still set gfx.webrender.dcomp-apply-1704954
to override
this as needed for testing (e.g.) fixes for bug 1638709.
Depends on D176842
Assignee | ||
Comment 4•2 years ago
|
||
DWM doesn't update its cached nonclient region information when a window
changes its client area without changing its actual size.
This happens in Firefox when a maximized window becomes fullscreen. If
this happens, "flicker-resize" the window to force DWM to update.
Depends on D176843
Comment 6•2 years ago
|
||
Backed out for causing gtest failures regarding WebRenderNvidiaHighMixedRefreshRateNightly
Assignee | ||
Comment 7•2 years ago
|
||
The failing gtest was testing for behavior that was deliberately removed in D176843. Removed and retested here; attempting reland.
Comment 9•2 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/f98b225696bc
https://hg.mozilla.org/mozilla-central/rev/de9223a8d783
https://hg.mozilla.org/mozilla-central/rev/40bd3180e96c
https://hg.mozilla.org/mozilla-central/rev/dd09461ffef5
Assignee | ||
Comment 10•2 years ago
|
||
Comment on attachment 9331027 [details]
Bug 1830792 - [1/4] Revert default to DXGI_SWAP_EFFECT_FLIP_SEQUENTIAL r?sotaro
Beta/Release Uplift Approval Request
- User impact if declined: Users who have DirectComposition disabled (e.g. due to the workaround of bug 1704954) may experience video tearing in fullscreen video on release of Fx113, as reported by one user here.
If so, this is probably worse than than the current fullscreen-clipping bug, which can be fixed merely by exiting and reentering fullscreen.
- Is this code covered by automated tests?: No
- Has the fix been verified in Nightly?: Yes
- Needs manual test from QE?: No
- If yes, steps to reproduce:
- List of other uplifts needed: None
- Risk to taking this patch: Low
- Why is the change risky/not risky? (and alternatives if risky): This is not particularly risky, despite the very late state of the release cycle, because it merely reverts a default preference-setting (which is not even checked unless the user is already in fallback code) to what it was in Fx112 (the current release).
Note that the other commits in this patchset are riskier and should not be uplifted.
- String changes made/needed:
- Is Android affected?: No
Comment 11•2 years ago
|
||
Comment on attachment 9331027 [details]
Bug 1830792 - [1/4] Revert default to DXGI_SWAP_EFFECT_FLIP_SEQUENTIAL r?sotaro
Fx113 is in release, switching beta uplift request to release uplift request
Comment 12•2 years ago
|
||
Comment on attachment 9331027 [details]
Bug 1830792 - [1/4] Revert default to DXGI_SWAP_EFFECT_FLIP_SEQUENTIAL r?sotaro
Approved for 113.0.1.
Comment 13•2 years ago
|
||
bugherder uplift |
Comment 14•2 years ago
|
||
Added to the 113.0.1 relnotes:
Fixed an issue which may cause users in some configurations to experience tearing when watching videos in fullscreen mode
Comment 15•2 years ago
|
||
I've tried to reproduce this using a couple of affected builds mentioned in Bug 1763981 (Firefox 99.0, 104.0.2) with Win 11 x64. It didn't reproduce on my laptop which had connected an external 2k monitor.
Brandon, Asidius, since you've encountered this in Bug 1763981, could you please verify the tearing issue when watching videos in fullscreen, and also if Firefox correctly enters into fullscreen mode on the following builds:
Assignee | ||
Comment 16•2 years ago
|
||
Apparently Bugzilla is preventing the needinfo?d users from responding here. I'm reopening the original bug for further commentary.
Description
•