Rerun viewer always loads at 2x the size of inner_size_points from app.ron

[jleibs]

Context

Affects: Linux (Arch) on Wayland (Hyprland)

This seems to be related to that fact that I have configured scaling on my monitor.

In hyprland.conf:

monitor=DP-1,3840x2160@120Hz,1440x600,1.25

The format for this clause is: monitor = name, resolution, position, scale

(The same problems occurs for integer scaling using a value like 2)

If I disable scaling and use:

monitor=DP-1,3840x2160@120Hz,1440x600,1

the problem goes away.

Observed behavior

If I start with app.ron showing 640x480

➜  cat .local/share/rerun/app.ron | grep window
    "window": "(inner_position_pixels:None,outer_position_pixels:None,fullscreen:false,inner_size_points:Some((x:640.0,y:480.0)))",

When I launch the viewer, the actual viewer ends up 1280x960:

Window 643b6de65a40 -> Rerun Viewer:
	mapped: 1
	hidden: 0
	at: 2336,984
	size: 1280,960
	workspace: 4 (4)
	floating: 1
	pseudo: 0
	monitor: 0
	class: rerun
	title: Rerun Viewer
	initialClass: rerun
	initialTitle: Rerun Viewer
	pid: 2642845
	xwayland: 0
	pinned: 0
	fullscreen: 0
	fullscreenClient: 0
	grouped: 0
	tags: 
	swallowing: 0
	focusHistoryID: 2

When I close the viewer, the new 1280x960 value ends up stored back in app.ron:

➜  cat .local/share/rerun/app.ron | grep window
    "window": "(inner_position_pixels:None,outer_position_pixels:None,fullscreen:false,inner_size_points:Some((x:1280.0,y:960.0)))",

Which then doubles again on the next load.

[jleibs]

A bit of debug investigation:

The monitor appears to be returning some incorrect value here:

egui/crates/egui-winit/src/lib.rs

Line 1573 in 36a70e1

|m| m.scale_factor() as f32,

On my system this is returning a value of "2", which is definitely wrong, though it's not clear to me if the correct value is 1 or 1.25.

By contrast, here:

egui/crates/egui-winit/src/window_settings.rs

Lines 22 to 24 in 36a70e1

	let inner_size_points = window
	.inner_size()
	.to_logical::<f32>(egui_zoom_factor as f64 * window.scale_factor());

window.scale_factor() is returning 1.25.

But the fact that I get a doubling every time, rather than an increase of 2/1.25 suggests that the "2" would need to be a "1", so there's still some additional factor in how this needs to fit together to work properly.

[jleibs]

Also, if any other Hyprland users happen to come across this, you can work around it by overriding the size with a windowrule. e.g.:

windowrulev2 = float,class:rerun
windowrulev2 = size 1920 1080, class:rerun

[emilk]

eframe prefers logical coordinates ("ui points") for everything, which means an eframe windows dragged from one screen to another should preserve the same logical size, though get a different physical/pixel size (due to monitors having different scaling). However, this can cause bugs if the DPI scaling is guessed incorrectly on save/load. It is also complicated by egui's scale factor.

There also have historically been inconsistencies with how things work in winit based on different platforms.

In short: the code is very messy, and I have no clear idea how to make it better.

Maybe we should store window size as physical pixels… but then the window is likely to change size if you close the app on one monitor and then open it on another. We could also try storing the DPI scale alongside the window size.

Still, by your reports, it seems like the system is inconsistent/unreliable in reporting the scale factor.

NOTE: please make sure egui_zoom_factor is 1.0 to rule out that as a source of bugs

---

Relevant and suspicious code can be found in:

• https://github.com/emilk/egui/blob/master/crates/egui-winit/src/window_settings.rs

• egui/crates/egui-winit/src/window_settings.rs

  Lines 69 to 73 in 36a70e1

  	let monitor_scale_factor = if let Some(inner_size_points) = self.inner_size_points {
  	find_active_monitor(egui_zoom_factor, event_loop, inner_size_points, &pos)
  	.map_or(1.0, |monitor| monitor.scale_factor() as f32)
  	} else {
  	1.0

• egui/crates/egui-winit/src/window_settings.rs

  Lines 90 to 96 in 36a70e1

  	if cfg!(target_os = "macos") {
  	// Mac sometimes has problems restoring the window to secondary monitors
  	// using only `WindowBuilder::with_position`, so we need this extra step:
  	if let Some(pos) = self.outer_position_pixels {
  	window.set_outer_position(winit::dpi::PhysicalPosition { x: pos.x, y: pos.y });
  	}
  	}

• egui/crates/eframe/src/native/wgpu_integration.rs

  Lines 921 to 923 in 36a70e1

  	let window = egui_winit::create_window(egui_ctx, event_loop, &viewport_builder)?;
  	epi_integration::apply_window_settings(&window, window_settings);
  	Ok((window, viewport_builder))

• egui/crates/egui-winit/src/lib.rs

  Lines 1560 to 1577 in 36a70e1

  	// We set sizes and positions in egui:s own ui points, which depends on the egui
  	// zoom_factor and the native pixels per point, so we need to know that here.
  	// We don't know what monitor the window will appear on though, but
  	// we'll try to fix that after the window is created in the call to `apply_viewport_builder_to_window`.
  	let native_pixels_per_point = event_loop
  	.primary_monitor()
  	.or_else(|| event_loop.available_monitors().next())
  	.map_or_else(
  	|| {
  	log::debug!("Failed to find a monitor - assuming native_pixels_per_point of 1.0");
  	1.0
  	},
  	|m| m.scale_factor() as f32,
  	);
  	let zoom_factor = egui_ctx.zoom_factor();
  	let pixels_per_point = zoom_factor * native_pixels_per_point;

[jleibs]

Confirmed egui_zoom_factor is 1.0