container, transaction: align to fractional grid

[agorgl]

Adapts to wlroots wlr_scene breaking changes introduced by PR https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/5071

Implements proper alignment to fractional grid thus solving all of the blurrying problems and border size mismatches in sway.

Fixes: #8131, #8117 (and many more like these)
Supersedes: #8660

[alex-huff]

This also fixes #8686 and removes the need for #8703.

[kennylevinsen]

This also fixes #8686 and removes the need for #8703.

I merged the bugfix PR first though.

[agorgl]

This also fixes #8686 and removes the need for #8703.

I merged the bugfix PR first though.

No problem, I will rebase to latest master to include this!

[agorgl]

Rebased to latest master to resolve conflicts (and include the above fix)

[vyivel]

Getting various gaps between borders and window contents, e.g.:

Is this intentional/fixable?

[agorgl]

Getting various gaps between borders and window contents
Is this intentional/fixable?

Yes this is something that will be fixed with another wlroots PR that will replace pixman_region64f_translate usages with pixman_region64f_translatef usages to avoid precision loss because the first one accepts ints instead of doubles as parameters.

I believe for now we can proceed with the rest

[agorgl]

Latest wlroots (from the related PR) solves these small precision losses, as it replaces usage of pixman_region64f_translate with pixman_region64f_translatef so the above problem is now gone.

[LaserEyess]

I have been testing this for two weeks with no regressions or bugs that I know of

[vyivel]

Still getting small gaps; container boundaries get slightly misaligned.

[agorgl]

Still getting small gaps; container boundaries get slightly misaligned.

I think this is an issue that also happens on latest stable (1.11) version (I just tried it).
Slightly resizing floating windows can lead to these kind of gaps shown in the screenshot.

How exactly did you reproduce this? With the same scaling factor as in the screenshot (1.14), spawning foot or alacritty instances and making them floating do not immediately lead to these small gaps around their containers for me, only after trying to slightly resize them I can see them

[agorgl]

Hmm, after a few more tests this issue seems to be fairly prominent with foot. With alacritty this does not seem to be the case in latest stable, but in this PR if you carefully resize I can reproduce the slight gap in floating windows. Will look into this a bit more to fix it.

P.S. using very odd scale values like 1.14 or 2.68 seems to help reproduce this, with mine that was 1.75 was not easily reproducible

[agorgl]

I found the problem! It was a misalignment for the right and bottom border rects, due to content width and height not being aligned to pixel grid. @vyivel, could you check again please?

[GreyXor]

Like in wlroots: I’ve been using this branch for two weeks now without noticing any issues. Thank you very much @agorgl

[dawsers]

First of all, thank you for this effort, it seems the right way to fix this issue. I have a question, though.

You make an effort to align the content to pixel boundaries when taking into account buffers will be scaled by the output scale. For this, you modify the widths and heights of containers to be integer values when corrected by the output scale, which seems the right way. That way, the buffers will occupy an integer number of pixels in the output.

The problem I see, and maybe I am not understanding something, is sway/tree/view.c:view_configure() will then only accept integer values for the width and height value, and it will be what it sends to the clients to get their buffers. This integer values will be in logical (not buffer) space, so your efforts to create a width and height that is properly aligned when multiplied by the output scale will be lost there. Am I misunderstanding something?

From my (maybe wrong) point of view, I think you may need some magic there, so the client receives a buffer size request that is of a size that turns into an integer size in the output at the native scale, or simply assume the size of the buffer will be integer (whatever) and try to align the origins.

[agorgl]

The problem lies in the wayland protocol in this case. The configure event sends width and height as (logical) integers, so some careful planning is required in both sides (sway <-> wlroots). We send some integer values from sway that when they reach wlroots and it scales and rounds them, they will end up as the original values sent in the configure event. It is like sway foresees the kind of rounding wlroots will do, and compensates for that in the width/height values of the configure event.

[tekstryder]

thus solving all of the blurrying problems

As noted in #8131, after some testing this, I've found various fractional scales which still produce blurry rendering.

Also, no differences from current git master in this regard.

[agorgl]

Please provide the exact client used, and try to reproduce this with foot that has a correct fractional scaling implementation. If this cannot be reproduced with foot in the same position/size as the app you are using, it is probably a client/toolkit issue.

[tekstryder]

Thanks! All the details are noted here: #8131 (comment).

Sorry I'd linked to the general bug, not my specific comment. Didn't want to copy that whole thing into the MR thread.

Cannot reproduce with foot or other GTK3/4 clients. Issue is specific to ptyxis terminal.

[tekstryder]

Slightly resizing floating windows can lead to these kind of gaps

It was a misalignment for the right and bottom border rects, due to content width and height not being aligned to pixel grid. @vyivel, could you check again

I don't see a response to your requested feedback, but I can reproduce the small gaps in foot from a small resizing.

I think this is an issue that also happens on latest stable (1.11) version (I just tried it).

Confirmed this also occurs on current git master, so nothing to do with this PR.

Still using this patch + wlroots!5071 + wlroots!5159 for good measure, as I build against Wayland 1.24 and that fixes its respective issue.

No regressions noted.