Giters

labwc / labwc

A Wayland window-stacking compositor

Home Page:https://labwc.github.io

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Damage issues with client side decorations and scale > 1

knm100 opened this issue · comments

commented

environment: vmware 17.5.1, arch+labwc 7.1
When scale is greater than 1 by kanshi, there will be a flash on the right and bottom border of chromium and filechoose.
it only appears on the half of the screen of right side, not on the left side.
on labwc 6.6, It didn't appear.

1.mp4
commented

That seems to be an issue with the damage detection of client side decorations. We do have reports about issues with vmware in particular since we switched to wlroots 0.17.x. Do you run the latest wlroots patch release (0.17.2 currently)?

commented

I have no clue, but launching chromium as a wayland client with --enable-features=UseOzonePlatform --ozone-platform=wayland, or using egl as its renderer with --use-gl=egl (maybe --use-gl=desktop?) might fix the issue.

commented

That seems to be an issue with the damage detection of client side decorations. We do have reports about issues with vmware in particular since we switched to wlroots 0.17.x. Do you run the latest wlroots patch release (0.17.2 currently)?

Yes, Labwc run on wlroots0.17.2
swappy-20240409-173004

commented

Well, this seems to be a wlroots 0.17.x / vmware (more specifically their virtualized GPU drivers) interaction issue (at least I never heard of this issue before). I don't think labwc can do much about it, you might be able to work around it by starting labwc with software rendering (WLR_RENDERER=pixman labwc) but it might come at a performance cost.

commented

I have no clue, but launching chromium as a wayland client with --enable-features=UseOzonePlatform --ozone-platform=wayland, or using egl as its renderer with --use-gl=egl (maybe --use-gl=desktop?) might fix the issue.

I pretty sure that chromium run on wayland, because i compiled the labwc wiht -Dxwayland=disabled.
I will try --use-gl=egl

commented

Confirm that using ssd can fix it

commented

It might be caused by transparent drop-shadows. Do you still get it if you run labwc like this: WLR_SCENE_DISABLE_VISIBILITY=1 labwc

Ref:

commented

It might be caused by transparent drop-shadows. Do you still get it if you run labwc like this: WLR_SCENE_DISABLE_VISIBILITY=1 labwc

Ref:

didn't take effect.
image001

commented

Reproduced on wlroots 0.17.2 running on bare metal, default EGL renderer, on Radeon RX 6700 XT using radeonsi via Mesa 24.0.5, specifically with GNOME Calculator. Client side decorations with soft shadows it is. They don't appear to be propagating damage of translucent pixels to underlying surfaces until those surfaces damage themselves directly.

Video_2024-04-19_18-05-20.mp4
commented

I can't currently debug this so help would be much appreciated.

It might be related (though seems unlikely to me) to the early return in https://github.com/labwc/labwc/blob/master/src/common/scene-helpers.c#L60, so one could test if adding wlr_damage_ring_rotate(&scene_output->damage_ring); before the return false; fixes things (and doesn't break anything else).

There is some upstream discussion about this whole thing in case somebody wants to dive deep into wlroots damage tracking internals: https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/4253

commented

Thanks for the fix. As this is a bug in wlroots 0.17.x and we can't work around it from the labwc side there is not much we can do here. Thus closing the issue.

@vyivel
Any chance of marking the PR as backport in case there is a wlroots 0.17.4 at some point?