Description
Hey there. First of all, thanks for this glue package, it's made playing around with egui
much easier :)
I noticed that, running the wholesome
example on macOS, that pixel density / HiDPI / whatever you want to call it was not taken into account. In other words, logical pixels and physical pixels were treated as the same thing, resulting in very small rendering. Note the disparity between the size of the window title and the content of the window:
I did find scale_factor_override
in WindowDescriptor
, but adjusting that only resulted in the size of the window changing. That is, if I tried to create a window 500x500px and set a scale_factor_override
of 2
, then the window would be 1000x1000px, but the content was still the same size.
Investigating a bit further, I found that egui_winit
handles this sort of scaling via the set_pixels_per_point
method on egui_winit::State
. This state is created in integration::Gui::new
, and adding the following before returning from the constructor results in the (imo) "correct" content size:
egui_winit.set_pixels_per_point(surface.window().scale_factor() as f32);
So, long story short, this results in a bunch of questions from my side:
- Do you think it's desirable to add this functionality to the
egui_winit_vulkano
crate?- If so, I think it'd be handy to both detect the default as shown above, but also allow the user to chose the
pixels_per_point
manually, if desired.
- If so, I think it'd be handy to both detect the default as shown above, but also allow the user to chose the
- Could you elaborate what the the current idea behind
scale_factor_override
is?