-
Notifications
You must be signed in to change notification settings - Fork 16.4k
fix: abnormal behavior of windows background material #47386
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
7f5ef3c
to
5778823
Compare
Fantastic fix! Thanks for digging into Chromium and find out why. Wanted this feature for long time. |
5778823
to
89f51c4
Compare
// We avoid doing this when the window is translucent (e.g. using | ||
// backgroundMaterial effects), because setting zero insets can interfere | ||
// with DWM rendering of blur or acrylic, potentially causing visual | ||
// glitches. | ||
const std::string& bg_material = native_window_view_->background_material(); | ||
if (!bg_material.empty() && bg_material != "none") { | ||
return false; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Has it been verified that these translucent window edges don't bleed in a multi monitor setup ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@deepak1556 no, and i might need some assistance with that as I've only one monitor!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I’m using a multi-monitor setup and everything looks fine during development. However, to be safe, it would be best if you could verify it on your end. @codebytere
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tested the latest changes and they seem to regress the edges fix, display information
Displays:
Resolution: 2560 x 1600 Retina
Main Display: Yes
PHL27E1N5600H:
Resolution: 2560 x 1440 (QHD/WQHD - Wide Quad High Definition)
Overlay buttons are misaligned and edges bleed into the secondary monitor
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not experiencing any of these issues with my multi-monitor system on Windows. @deepak1556 were you testing on macOS?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry missed this thread, I was testing with a remote setup. https://devbox.microsoft.com/ connected from macOS windows app with multiple displays.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@deepak1556 i can try to look into this but also do we think this is potentially a worthwhile edge case to accept in service of fixing the other outstanding issues, at least for a while?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah given this only affects remote case, I don't mind following-up on that separately to avoid blocking this PR.
0e45708
to
bee0a68
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unfortunately, #43345 seems to still repro for me on Windows 11 23H2.
This was the method I was trying https://gist.github.com/edbf82eca6fcfb92cf9abcb7e0161831
0fc3fd3
to
ed49934
Compare
9212e93
to
4b8244c
Compare
@mlaurencin just pushed a fix for #43345 - can you test again? it's working for me now. |
cf95653
to
8131f3d
Compare
I have automatically backported this PR to "38-x-y", please check out #47814 |
* fix: abnormal behavior of windows background material Co-authored-by: Shelley Vohr <shelley.vohr@gmail.com> * chore: update patches * fix: setting background material after init --------- Co-authored-by: zoy <zoy-l@outlook.com> Co-authored-by: patchup[bot] <73610968+patchup[bot]@users.noreply.github.com>
Hi @codebytere would it be possible to backport the fix in 37-x-y? |
@sbenmoussati hey sure - i'm out until thursday but i'll prioritize it then :) |
Hi @codebytere I know you're probably busy — just wanted to gently check if there's any chance the fix could be backported in 37-x-y? |
@codebytere has manually backported this PR to "37-x-y", please check out #47956 |
@codebytere has manually backported this PR to "36-x-y", please check out #47957 |
The underlying Electron issue causing glitchy behavior was fixed: electron/electron#47386
Description of Change
Follow-up to #46855
Closes #47366
Closes #46753
Closes #43345
Closes #43196
Closes #46882
GetDwmFrameInsetsInPixels
to determine whether an update is needed and setsDwmExtendFrameIntoClientArea
, which disrupts the background effect.Checklist
npm test
passesRelease Notes
Notes: Fixed applying background material correctly when creating windows on Windows, restored animations, and also fixed the issue where dynamically setting the background material had no effect.