windows: Properly handle DPI

[JunkuiZhang]

As I mentioned before, there are the following issues with how GPUI handles scale factors greater than 1.0:

1. The title bar buttons do not function correctly, with minimizing button performing maximization and maximizing button performing closure.
2. As discussed in Better Windows support #8809, setting a scale factor greater than 1.0 causes GPUI's drawing content to be pushed off the screen.

This PR introduces LogicalSize and PhysicalSize to differentiate between coordinate systems for proper GPUI rendering, and now scale factors above 1.5 are working correctly.

Zed with a scale factor equals 1.5, and change between different scale factors:

10.mp4

Release Notes:

• N/A

[zaucy]

Instead of ignoring the result and inspecting the error I'd suggest just using .log_err() or something. If you want to add context to the error you could do something like this:

Suggested change

	let _ = SetWindowPos(
	self.hwnd,
	None,
	rect.left,
	rect.top,
	width,
	height,
	SWP_NOZORDER | SWP_NOACTIVATE,
	)
	.inspect_err(|_| {
	log::error!(
	"unable to set window position after dpi has changed: {}",
	std::io::Error::last_os_error()
	)
	});
	SetWindowPos(
	self.hwnd,
	None,
	rect.left,
	rect.top,
	width,
	height,
	SWP_NOZORDER | SWP_NOACTIVATE,
	)
	.context("unable to set window position after dpi has changed")
	.log_err();

[JunkuiZhang]

Some ffi functions return just the error code, no usefull infomation. So I use inspect_err to pull error message from windows by calling last_os_error, .log_err() will just log the err code.

[zaucy]

The windows crate actually wrap the last error message in their functions. I tested the above snippet I suggested and it works as expected. the os error message is printed

[JunkuiZhang]

I see, thanks for the tips!

[mikayla-maki]

we can use the px() helper for these.

[mikayla-maki]

I think that, rather than creating this type and these new helpers, we should just be consistently using the existing GPUI types, Pixels, GlobalPixels, ScaledPixels, DevicePixels, Size, etc.

[JunkuiZhang]

Using these aliases might make things clearer, I guess. It was only after reading the macOS impls that I understood the things realy goes here. Should we remove the type aliases and keep this struct? Any suggestions?

[mikayla-maki]

Unless there's a compelling code reason to do otherwise, I think the best solution would be to take all of these type aliases and the WindowMetrics struct out, and to just have origin: Point<GlobalPixels>, size: Size<GlobalPixels>, and scale_factor: f32 (with appropriate Cell<> wrapping). As that's the only data you actually need to store. The logical size and bounds can be recomputed on the fly from those values.

Once you have those inlined, I think you could just make a fn logical_point(x, y, scale_factor) -> Point<Pixels> helper that you use when you need it :)

[JunkuiZhang]

Makes sense.