Closed x3ro closed 2 years ago
Yea, this should not occur. Let me get back to you when I get a moment :) tonight or over the weekend
Looks like I broke it when updating to new egui_winit
whose api changed. I'll make a fix! @x3ro
scale_factor_override
is used in the window builder in vulkano-utils
. I think it just tells winit what the scale factor should be (if it's set), but if we don't tell egui_winit
what the scale factor is, then egui will look wrong.
egui_winit
is already publicly exposed from Gui
thus you can set the scale factor for egui later if you wish.
Thanks for reporting and using this lib!
Nice, thanks for the quick fix! :)
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
inWindowDescriptor
, but adjusting that only resulted in the size of the window changing. That is, if I tried to create a window 500x500px and set ascale_factor_override
of2
, 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 theset_pixels_per_point
method onegui_winit::State
. This state is created inintegration::Gui::new
, and adding the following before returning from the constructor results in the (imo) "correct" content size:So, long story short, this results in a bunch of questions from my side:
egui_winit_vulkano
crate?pixels_per_point
manually, if desired.scale_factor_override
is?