mirror of
https://github.com/servo/servo.git
synced 2025-10-04 02:29:12 +01:00
ba67a0a4fb
The current implementation has 3 main issues related to HiDPI:
1. When the window moves from a screen with scale factor of 1.5 to one
with 1 and back to 1.5, the minibrowser toolbar actually ends up
being scaled by a factor of 2.25 instead of 1.5. This is because we
currently use the [set_pixels_per_point] method on egui's Context,
but calling this with a value of `ppp` will modify egui's internal
'zoom factor' to be:
```
zoom_factor = ppp / native_points_per_pixel.
```
where `native_points_per_pixel` is the window system scale factor.
The idea is egui can calculate the final scale factor for translating
its logical points to physical pixels as:
```
points_per_pixel = zoom_factor * native_points_per_pixel
```
where zoom_factor is a factor used for Ctrl+Plus, Ctrl+Minus
behaviour. The problem is when we handle the ScaleFactorChanged winit
event due to window moving between screens, the
`native_points_per_pixel` still has the value of the previous
screen's native scaling factor and not the current screen's factor.
This seems to be the case even if we pass the ScaleFactorChanged
event to egui before we call `set_pixels_per_point`.
2. The egui logic for handing Ctrl+Plus, Ctrl+Minus and Ctrl+0 doesn't
interact well with servoshell's device-pixel-ratio CLI argument which
allows the user to override the HiDPI factor. For example, Ctrl+0
will cause egui to reset the zoom_factor to 1.0 instead of the
override we wanted. Another issue is egui's Ctrl+Plus/Ctrl+Minus
will scale the minibrowser in increments of 0.10 whereas
Servo's own page zoom doesn't (it keeps multiplying by 1.1, so the
actual increments are 0.1, 0.21. 0.33 etc)
3. The inital window size calculation on Linux currently assumes a scale
factor of 1.0. This means the window doesn't have the expected
default logical size of 1024*740 on HiDPI systems. On a screen with
HiDPI factor of 1.5, the logical window size ends up being 682x493.
This change addresses all 3 issues:
For 1, switch to the `set_zoom_factor` method of egui context
to avoid the issue with scaling by incorrect native_points_per_pixel.
To allow for the device-pixel-ratio override to work, we calculate the
actual zoom_factor as `device-pixel-ratio / window's scaling factor`.
For 2, disable egui's handling of Ctrl+Plus, Ctrl+Minus, Ctrl-0
shortcuts. It is unclear whether the current behaviour of scaling
both the toolbar and the web page was intentional, or just an accident.
This behaviour is also different from other browser where page zoom
doesn't scale the GUI, so it doesn't seem like a regression to me.
For 3, use LogicalSize type of winit which lets the physical size
calulation to be handled by winit using the windows's actual HiDPI
factor instead of hardcoded 1.0.
[set_pixels_per_point]:
|
||
|---|---|---|
| .. | ||
| protocols | ||
| app.rs | ||
| cli.rs | ||
| egui_glue.rs | ||
| embedder.rs | ||
| events_loop.rs | ||
| geometry.rs | ||
| headed_window.rs | ||
| headless_window.rs | ||
| keyutils.rs | ||
| minibrowser.rs | ||
| mod.rs | ||
| tracing.rs | ||
| webview.rs | ||
| window_trait.rs | ||