[Wayland][WebRender] Firefox does not adjust scale when switching DPI
Categories
(Core :: Widget: Gtk, defect, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr68 | --- | unaffected |
firefox74 | --- | disabled |
firefox75 | --- | disabled |
firefox76 | --- | fixed |
People
(Reporter: michaelaquilina, Assigned: stransky)
References
(Blocks 1 open bug, Regression)
Details
(Keywords: regression)
Attachments
(4 files)
241.71 KB,
image/png
|
Details | |
660 bytes,
patch
|
Details | Diff | Splinter Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
Bug 1612377 [Wayland] Update opaque region and widget scale factor when screen DPI changes, r?jhorak
47 bytes,
text/x-phabricator-request
|
Details | Review |
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:72.0) Gecko/20100101 Firefox/72.0
Steps to reproduce:
sway version 1.4 (Wayland)
-
Open Firefox on a non hidpi monitor (e.g. an external monitor). Laptop screen is currently disabled
-
Disconnect external monitor and re-enable inbuild hidpi monitor
Actual results:
Firefox is scaled to the wrong size. It chooses a scale which is too large for it (which is strange as in the past it was too small instead). I've included a screenshot showing how this looks
running journalctl -e shows a large number of the following error
gdk_monitor_get_scale_factor: assertion 'GDK_IS_MONITOR (monitor)' failed
Expected results:
Firefox should have adjusted its scale correctly for the hidpi monitor.
This used to work in previous firefox versions
Updated•5 years ago
|
Assignee | ||
Comment 1•5 years ago
|
||
Yes, it's known bug with WebRender enabled. Can you confirm it happens only when WebRender is enabled or do you see that with SW render too?
Reporter | ||
Comment 2•5 years ago
|
||
Just confirmed that it only happens when WebRender is enabled
Assignee | ||
Updated•5 years ago
|
Comment 4•5 years ago
|
||
I've just noticed that new (or closed and then restored) windows are drawn correctly. (Which, if nothing else, allows for working around this without rebooting the entire session).
Comment 5•5 years ago
|
||
Happens also when layers.acceleration.force-enabled is set to true.
Works fine when both accel and webrender are turned off.
Comment 6•5 years ago
|
||
Should this bug block "wayland" and "wr-linux" (I can't edit the bug myself)?
Comment 7•5 years ago
|
||
This is a regression, it worked fine in FF71 with webrender or layers accel or both enabled.
Comment 9•5 years ago
|
||
(In reply to luis.pabon from comment #7)
This is a regression, it worked fine in FF71 with webrender or layers accel or both enabled.
If anyone could run mozregression to find when it broke (you can run it with --prefs gfx.webrender.all:true
) then it'd be quite amazing.
Comment 10•5 years ago
|
||
Done.
> env MOZ_ENABLE_WAYLAND=1 mozregression --good 2019-08-26 --pref gfx.webrender.all:true
[...]
6:20.84 INFO: No more integration revisions, bisection finished.
6:20.84 INFO: Last good revision: d6709b4ccf48e8efa8a6efcd478f97c7ee4e2d48
6:20.84 INFO: First bad revision: f389488df7cc2bf33d7d44393f2d18a501aaef76
6:20.84 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=d6709b4ccf48e8efa8a6efcd478f97c7ee4e2d48&tochange=f389488df7cc2bf33d7d44393f2d18a501aaef76
- f389488 Bug 1592933 - [Wayland] Cache scale factor for toplevel windows, r=jhorak
- 8e5e094 Bug 1592933 - [Wayland] Get scale factor from nsWindow::GdkScaleFactor() and set it when wl_surface/egl_window is used for rendering, r=jhorak
Bug 1592933 seems to me like a pretty clear winner here.
Updated•5 years ago
|
Updated•5 years ago
|
Comment 11•5 years ago
|
||
Same symptoms as old bug https://bugzilla.mozilla.org/show_bug.cgi?id=1528581 which was fixed sometime prior to this regression.
Comment 12•5 years ago
|
||
Rather, old fixed bug is https://bugzilla.mozilla.org/show_bug.cgi?id=1507989 (the other is dup)
Comment 13•5 years ago
|
||
I think this is the same as bug 1607745
Comment 14•5 years ago
|
||
So, to make cache work for us we just need to not move windows from the display they were open on. If a new window is needed, make sure to have cursor on the proper display before firing shortcut.
Comment 17•5 years ago
|
||
Comment 18•5 years ago
|
||
I took a look at the code. The issue seems to be that nothing in OnScaleChanged calls wl_surface_set_buffer_scale. The code for that was removed in Bug 1592933 and it's not clear to me what the replacement is supposed to be since I'm not familiar at all with the code.
The attached patch fixes it for me (Arch Linux, sway 1.4 and sway master). It calls wl_surface_set_buffer_scale right from OnScaleChanged. Again, someone more knowledgeable with the code will probably know what's the cleaner/right fix.
Assignee | ||
Comment 20•5 years ago
|
||
Assignee | ||
Comment 21•5 years ago
|
||
- Integrate scale factor setup to moz_container_get_wl_surface() and don't call it explicitly.
- No need to set it explicitly at nsWindow::GetWaylandSurface().
- Update client offset when scale changes in CSD mode by UpdateClientOffsetFromCSDWindow().
- Update scale factor/opaque region on EGL immediately.
Depends on D68351
Assignee | ||
Comment 22•5 years ago
|
||
try: https://treeherder.mozilla.org/#/jobs?repo=try&revision=ba679db57659c3ab6e7bc532513285bfc46e283b
Assignee | ||
Comment 23•5 years ago
|
||
Thanks Dario, I used your patch as a base for the two above.
Assignee | ||
Updated•5 years ago
|
Comment 24•5 years ago
|
||
Comment 25•5 years ago
|
||
Just tested a build with the latest patches, and it works great!
Thanks a lot Martin!
Assignee | ||
Comment 26•5 years ago
|
||
I'm glad to hear so :)
Comment 27•5 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/22fa6cbe3298
https://hg.mozilla.org/mozilla-central/rev/b651ff8263af
Comment 28•5 years ago
|
||
Thank you folks 👍
Updated•5 years ago
|
Description
•