Big performance regression caused by ˙Implement xcb input shapes #4036˙.

[Sinaaaa]

Hi!

Commit 27c8fa5 ˙Implement xcb input shapes #4036˙ is causing massive lag for me in AwesomeWM. I use gears.shape.rounded_rect for client borders & maybe the massive slowdown is related to that??? Like mod+dragging windows seems to be low fps and it's just jittery & if I spawn a terminal it's appearing with a 1s delay, If the computer is busy there is all around lag.

[Sinaaaa]

I have done some testing. It seems far less noticeable if the shape is rectangle or we are in the floating layout. (by far less I mean it's borderline placebo) When transitioning from smart gaps/border to rounded borders drawn is the laggiest moment.

So to produce big lag:

1. Have rounded_rect set as the window shape
2. Not be in the floating layout, I tested my own custom layout & awful.layout.suit.tile
3. Spawn a tile that will cause a layout reflow of some kind. With awful.layout.suit.tile this only happens when going from 1 client to 2 clients. Though I have not tested with smart gaps/smart border disabled yet.

edit: I tested octogon too & it's just as performant as rect, so I suppose the overhead is mostly impacting rounding only. No, I did not know that reload config after compiling awesome would load the new lua code. So MISTAKE & yes octogon is slow too.

[actionless]

was it ever working fast? and also how you solved non-aliased rounding?

usually people who need those, use picom

although you could simply disconnect from the signals which were added in the PR

[Sinaaaa]

was it ever working fast?

Yes, it's working very fast right now, on this version: HEAD is now at c68ca045 Update timer.lua (#4046)

how you solved non-aliased rounding?

I did not solve it. I'm alright with this.

usually people who need those, use picom

Not a fan of picom, so don't have it on unless necessary. It's slightly incompatible with my setup.

although you could simply disconnect from the signals which were added in the PR

Wait are you saying I can turn this off from my own rc.lua?

[Sinaaaa]

I have recorded two short clips with keyboard activation sounds to demonstrate, even though the footage doesn't do this justice the reality is worse than this & much worse when there is some background CPU load already. (the second video shows the lag)

https://github.com/user-attachments/assets/97e2f2af-b8e6-47dc-8fd3-d04068cf7986
https://github.com/user-attachments/assets/ac57324a-e184-40d5-8962-22e43d703377

[actionless]

Wait are you saying I can turn this off from my own rc.lua?

just copy the lines which connect signal and replace them to disconnect_signal

[actionless]

I did not solve it. I'm alright with this.

that's categorically tasteless to use AntiAliased-fonts but non-AA-graphics 😾

[Sinaaaa]

Wait are you saying I can turn this off from my own rc.lua?

just copy the lines which connect signal and replace them to disconnect_signal

capi.client.disconnect_signal("property::shape_client_bounding", shape.update.bounding) capi.client.disconnect_signal("property::shape_client_clip", shape.update.clip) capi.client.disconnect_signal("property::shape_client_input", shape.update.input) capi.client.disconnect_signal("property::size", shape.update.all) capi.client.disconnect_signal("property::border_width", shape.update.all) capi.client.disconnect_signal("internal::update_shapes", shape.update.all)

If all of these are added everything breaks. Like layouts produce a seemingly random arrangement & I cannot resize floating windows beyond a certain point etc..

capi.client.disconnect_signal("internal::update_shapes", shape.update.all) is enough to fix the lag, but this one thing is causing crazy weird behaviors with clicking into a client not working or scroll wheel not scrolling etc. New clients not always gaining focus depending on some criteria I cannot quite comprehend.

edit:

local shape = require("awful.client.shape")

client.disconnect_signal("internal::update_shapes", shape.update.all)
client.disconnect_signal("property::shape_client_input", shape.update.input)

shape.update.all = function(c)
    shape.update.bounding(c)
    shape.update.clip(c)
end

shape.update.input = function() end

This seems to do it, need to test it more, but I see no immediate problems, as ugly as it is to have something like this in rc.lua.

Anyway I find it hard to believe I'm the only one affected by this. Sure using rounded_rect or octogon for borders is super niche, but I have seen some really tasteful -unlike what I have- pixel artsy borders with lots of weird stuff on them. Would those people seriously not be affected by this commit, like is this really fine?

[actionless]

local shape = require("awful.client.shape")
client.disconnect_signal("internal::update_shapes", shape.update.all)
client.disconnect_signal("property::shape_client_input", shape.update.input)

i think only that should be enough

[Sinaaaa]

local shape = require("awful.client.shape")
client.disconnect_signal("internal::update_shapes", shape.update.all)
client.disconnect_signal("property::shape_client_input", shape.update.input)

i think only that should be enough

Tried it just now, would've loved it if that worked, but straight up saw lots of bugs, like couldn't drag the scrolltab in Firefox & new clients once again stopped reliably gaining focus..

[actionless]

i, see leaving it open so @DziubanMaciej as an author of the change could suggest more steps to investigate and eventually come up with the fix

or alternatively if this wouldn't happen we could just unmerge it, until it would be fixed

[DziubanMaciej]

It's a bit difficult for me to address this, since I don't observe any performance problems.

Are you compiling awesomeWM yourself? Would you be able to comment out the signalling of internal:: update_shapes and verify if it helps? I'd suspect this to be the problem.

Also what's your machine config? CPU, RAM, motherboard, etc.

[Sinaaaa]

It's a bit difficult for me to address this, since I don't observe any performance problems.

Are you compiling awesomeWM yourself? Would you be able to comment out the signalling of internal:: update_shapes and verify if it helps? I'd suspect this to be the problem.

Also what's your machine config? CPU, RAM, motherboard, etc.

Intel 4790k, Asus z97-p, 16gb ddr3 dual channel, I'm running awesomeWM on the haswell igpu & only that igpu has 3 displays connected. I will take a look about the commenting out bit.

(There is another person on discord whom experienced lag when modkey dragging windows.)

I'm assuming you want me to comment out this line: capi.client.connect_signal("internal::update_shapes", shape.update.all) I think I already tried the equivalent capi.client.disconnect_signal("internal::update_shapes", shape.update.all) this fixes the lag, but experienced crazy behaviors.

(this is what I wrote in an earlier comment here about doing this: but this one thing is causing crazy weird behaviors with clicking into a client not working or scroll wheel not scrolling etc. New clients not always gaining focus depending on some criteria I cannot quite comprehend.)

Wait never mind, you probably wanted the line in client.c: luaA_object_emit_signal(L, -1, "internal::update_shapes", 0);, I'll try that or rather I have tried that & it's the same thing as client.disconnect_signal ("internal::update_shapes", shape.update.all).

[Sinaaaa]

I have new information.

In my previous comments I said that client.disconnect_signal("internal::update_shapes", shape.update.all) is enough to fix the lag with many buggy behaviors emerging. Unfortunately that is not the case, it just improves the situation a lot & I have not noticed it at the time, but it's super clear that there is still lag alongside the weird behavior, it's just much less prominent. However I have an easy to see performance testing use case where it's super obvious, which is to spawn ~100 terminals while holding mod+enter. Though spawning just a second terminal is noticeably slower, just not unbearably so like with internal::update_shapes.

So @DziubanMaciej to reproduce, I suggest comparing terminal spawning while holding the spawning keybind, letting it spam at the keyboard's default repeat rate? Doing this in the fair layout with picom off with 4px thick rounded_rect shaped window borders, even on a very fast computer the lagginess difference should be very noticeable I presume. (use a fast terminal emulator like Xterm, Uxterm or Sakura, not a super slow one like Kitty)