search

canonical / mir

The Mir compositor
GNU General Public License v2.0
627 stars 100 forks source link

Placement and alignment of windows should not be affected by display scale #3553

Open Saviq opened 2 months ago

Saviq commented 2 months ago

These are two screenshots of the same surface at --display-scale 1.5, except one of them is moved 1 "unit" on both axes. image image

You should easily see the second one is blurred.

The problem is that it's aligned on half-pixel (or rather, on "logical" pixel that's a square of 1.5 pixels).

You can also see this with --display-scale 10 and trying to move a window - you'll only be able to move it in 10px increments.

Saviq commented 2 months ago

some scenarios need that ("cloning" with the second display with twice the dimensions and running at scale 2).

Originally posted by @AlanGriffiths in https://github.com/canonical/mir/issues/3555#issuecomment-2293170763

One alternative Alan mentioned is that we could align on pixel boundary at the compositing level.

Still, I think we can have better logic for the logical grid than we do now. If there's no overlap between displays, it'd be appropriate to have the grid be the output's physical grid. Overlap makes things trickier, but we also don't need to optimize for that.

AlanGriffiths commented 2 months ago

Still, I think we can have better logic for the logical grid than we do now. If there's no overlap between displays, it'd be appropriate to have the grid be the output's physical grid. Overlap makes things trickier, but we also don't need to optimize for that.

I don't think it is just about overlapping displays. Adjacent displays with different pixel density are also better handled by a logical grid.

I agree we could do better, just not that switching to a physical grid is a panacea

Saviq commented 2 months ago

Adjacent displays with different pixel density are also better handled by a logical grid.

Could you elaborate on that? I get it for surfaces spanning displays, but that's getting into corner cases I don't think we should optimize for.

Anyway, we need to spend proper time spec'ing this out.