surface: redesign state

[emersion]

• Rename invalid to committed - better ideas welcome!
• Move subsurface_position in wlr_subsurface
• Fix sx/sy handling
• Don't monkey-patch surface_damage and buffer_damage - add a new buffer damage region instead
• Make current and pending embedded structs
• Add a previous state
• Update cursor hotspot with buffer position

Test plan:

• Make sure damage tracking works on surfaces and subsurfaces (try gnome-calculator)
• Try with scaled and transformed outputs
• Try wleird's cursor example

See #1065

[ammen99]

Remove subsurface_position

Is there another way to get the subsurface position relative to its parent?

[emersion]

Is there another way to get the subsurface position relative to its parent?

Yes, this will be moved in wlr_subsurface.

[synaptiko]

Should it be 4 here?

[emersion]

Right, thanks!

[emersion]

I'm not really happy with the current wlr_surface_state struct. It contains both things from the client (fields from buffer to frame_callback_list) accumulated before commit and things computed on commit (width, height, s{x,y}, and I wanted to add the wlr_buffer?).

[emersion]

Still not sure how damage should be defined.

• What should be the (0, 0) point in the damage region? The top-left corner of the buffer or the top-left corner of the surface?
• Should it be in buffer-local coords or in surface-local coords? We loose precision if we do surface-local coords, and it's doesn't add a lot of complexity in the damage code - just one … / surface->current.scale somewhere, and one wlr_transform_compose(…, surface->current.transform) somewhere else.

[ammen99]

@emersion, as we're doing the damage for just convenience, I think it should be in surface local coordinates, because that's
what a compositor typically uses. In this case it'll also make sense to make (0,0) the top left corner of the surface. I'm however not sure how to do precision issues, maybe wlr_region_expand?

[ddevault]

It should be buffer local.

[ammen99]

It should be buffer local.

I'm not trying to argue, just asking out of interest: what makes you think this way?

[ddevault]

Can we just go with "it's been a long day and explaining the full answer is beyond the limits of my patience right now"?

[emersion]

Moved bits that are computed as a delta of two states (the enhanced damage, the surface position, the buffer itself) outside of wlr_surface_state.

Decided to use damage in buffer-local coordinates, so that you can apply scale and transform to this region in the exact same way you render the associated texture.

[emersion]

This PR is ready for review.

cc @Ongy @Timidger @ammen99: this is a breaking change.

[ammen99]

So, after this, what is the intended solution for #1065?

[emersion]

So, after this, what is the intended solution for #1065?

Let's continue to discuss this in the other issue.

[ddevault]

swaywm/sway#2185

Code looks good, running this as my daily driver for a while.

[ghost]

Pointer position is still off after applying this and the sway update PR. Do you compensate for scaling?

[emersion]

Pointer position is still off after applying this and the sway update PR. Do you compensate for scaling?

Input doesn't deal with scaling and transform. Can you describe how to reproduce? Are you sure you're running with the latest version of this branch? (A previous commit fucked up the input region)

[ghost]

Yep, this is with the latest version of this PR. There's no transform on anything, just scaling set in sway.
You've reproduced this before and I have mentioned this before too. Hotspot is fine, the image matches what's on the screen and sent as input, its just that if you open a right click menu its offset compared to the pointer location.

[emersion]

FYI I have input issues with some floating windows on Sway master (without this patch applied): swaywm/sway#2195

[emersion]

Hotspot is fine, the image matches what's on the screen and sent as input, its just that if you open a right click menu its offset compared to the pointer location.

Ah, so this is not a regression: this is a bug also there on master? How big is this offset?

[ghost]

In GTK - a few pixels (3 or 4) upwards and a pixel or two to the left of where the menu is created.
In xwayland (such as firefox), 6 or 7 pixels upwards (or downwards, if you try to create the menu too far down the screen) and about 1 or two pixels to the left.
Yes, this isn't a regression, its always been present, but since this commit touched some position code I thought it might also fix this issue.

[emersion]

Yes, this isn't a regression, its always been present, but since this commit touched some position code I thought it might also fix this issue.

I think this is more of a xdg-shell window geometry issue (this PR only updates the wl_surface implementation).

[emersion]

Bump: I've been using this for a few days.

[ddevault]

aight