Weird Lag when dragging floating windows

[System-x64]

on setting misc{animate_manual_resizes} to true, the window gets a weird lag or idk what to call it

https://user-images.githubusercontent.com/90208727/204487118-c616074f-5d5d-4f64-9a72-7112c315d42d.mp4

Is their anyway we could fix it cuz i really love animated resize but i hate this lag thing

[vaxerski]

only happens for a few people which does not include me, so I don't know what is the root cause.

[System-x64]

nvm

[EvilBoi123]

same, happen to me too

[ad-on-is]

Me too, I noticed this happens when I enable animations. Otherwise it's fine.

[vaxerski]

can someone share a minimal reproducible config?

[System-x64]

hyprland.txt

[System-x64]

Me too, I noticed this happens when I enable animations. Otherwise it's fine.

Yeah...but turning animations off also removes this resize animation...maybe thats why it works?

[System-x64]

it's something to do with animate_manual_resize only

[System-x64]

@vaxerski I found the possible cause of this issue, while looking through my config file, I noticed I had a separate windowsMove animation with its own separate bezier curve, I removed the windowsMove line and Voila! It is working as expected, my guess is that this lag issue only persists when we explicitly set a separate beizier curve for windowsMove?

[System-x64]

Is it possible to set this windowsMove thing to only apply to keybinds instead of both key and mouse binds? I suppose this would fix this issue without having to sacrifice my bezier style

[vaxerski]

thanks for identifying. I'll look into this.

Is it possible to set this windowsMove thing to only apply to keybinds instead of both key and mouse binds? I suppose this would fix this issue without having to sacrifice my bezier style

No.

[vaxerski]

check with b9812f8bc0f372875af8c332e4537fdbf2b99c23

[System-x64]

The lag does seem to get better (it's more responsive) but it's not completely gone, the best bet for now is to not put bezier for windowsMove all together

[ad-on-is]

Is it possible to set this windowsMove thing to only apply to keybinds instead of both key and mouse binds? I suppose this would fix this issue without having to sacrifice my bezier style

removing windowsMove did not solve the issue for me

[System-x64]

Can you share me your config? @ad-on-is

[ad-on-is]

Can you share me your config? @ad-on-is

Sure: https://pastebin.com/GCYkbCuW

[DashieTM]

~~@vaxerski sorry for the ping, but I have a likely cause for this, animate manual resizes = true. At least that setting causes this exact issue on 3 different pcs~~ long day sorry.

[vaxerski]

umm thats exactly what the reporter said...

it's just that I can't repro it. Been always using it on true and nothing's amiss

[DashieTM]

So I tried to build version 14, but I have no idea how to get the compatible wlroots for that. Either way I remember this starting to happen between version 14 to 16. I can't pinpoint it though sadly.

[vaxerski]

So I tried to build version 14, but I have no idea how to get the compatible wlroots for that.

git reset --hard <hash> --recurse-submodules && sudo make install ?

[DashieTM]

Ah thanks for the info, personally never used submodules with git, that's why I didn't understand that part, in the meantime I tried your binaries, and the problem starts at version 17. Tomorrow I might be able to be pinpoint when it started.

[vaxerski]

thank you. git bisect may come in handy.

[DashieTM]

Found it, this commit creates the bug: https://github.com/hyprwm/Hyprland/commit/8ffd244ef6cca76af51e283355ae048557510349

[vaxerski]

well that's anticlimactic. That's the commit that introduced the animations on dragging floating windows.

[DashieTM]

I was also extremely surprised, and I still can't figure out why though. When I move the window extremely slowly it works. But the moment I do it with a normal speed it has these small stops where it freezes. A brief guess would be a performance issue, but I doubt that an rx6600xt or a gtx 1070 wouldn't be good enough.

I guess my suggestion is to put this behind a different config flag, animate_mouse_windowdragging.

[vaxerski]

I mean, it could also be your curve.

How it's currently animated is that whenever you move your window by 1 pixel or more, it restarts the animation.

My guess is that it's not lag, but the animation curve snapping back to the start.

Can you try with a linear curve? it's 0.5,0.5,0.5,0.5.

[DashieTM]

Hmm, it doesn't make much of a difference, I guess there is always going to be a slight "delay" with animations, but it definitely doesn't feel right. Perhaps polling rate (and/or refreshrate etc ) might cause some issues here as well ? (I haven't checked how the tick is done)

[DashieTM]

I added that config flag for now in a pr -> https://github.com/hyprwm/Hyprland/pull/1658, not necessarily a fix, but this allows users to still get manual resizes without floating window animations.

[vaxerski]

you can't really fix it cuz it works as intended... #1658 merged

[vaxerski]

I also suppose misc:vfr = false doesn't fix this right?

[vaxerski]

patch.txt

please check out this patch

[DashieTM]

Neither of them made the result much different sadly.

[vaxerski]

can you try with the "default" curve?

[DashieTM]

I tried a lot of curves, including the default one with different "speeds".

[vaxerski]

I still can't repro it, even with configs provided by other people.

I'll be posting patches then and I'd like for everyone affected to try and report the results.

If someone has posted it doesn't work already, no need to affirm them. If someone posted it works though, feel free to double their comment so that I know it's not fixed just for them.

Please test this patch: patch.txt

[jacekpoz]

no changes to the bug with this patch, only difference I can see so far is the mouse cursor being reset to the default one

[vaxerski]

IIRC @jacekpoz your issue was not the lag but delay, which is intended.

[jacekpoz]

what do you mean intended it didn't happen before

[vaxerski]

misc:animate_manual_resizes and misc:animate_manual_windowdragging to false to get the "old" behavior.

[jacekpoz]

whoopsie daisy

[DashieTM]

Alright, here some feedback and some questions.

The performance has been improved by a lot on the default curves(very close to no difference to animation disabled), but now it definitely does depend on the curve used, some are still extremely bad, which makes sense ofc. Not every curve fits this animation.

Does the performance in the debug version differ much? I have not tested the regular installation yet, only via the debug environment. If so I will retest with the regular version.

And lastly, because of the dependency on a specific curve, I would suggest leaving this behind a config flag, might be enabled by default ofc should that be the idea.

Either way, nice work!

[vaxerski]

And lastly, because of the dependency on a specific curve, I would suggest leaving this behind a config flag, might be enabled by default ofc should that be the idea.

it is.

Patch pushed in 34685a836a40648167848060b48b62788cdcc85f. Lmk how it runs in a real session.

I am only interested in the choppiness. If it's delayed / slow, that's an effect of your windowsMove animation setting.

[GrabbenD]

Patch pushed in 34685a8. Lmk how it runs in a real session.

I tried this commit and here's my observations:

• Moving the window around very slowly is slightly choppy but it's very minor. It feels like something is catching the window or as if the window is moving between "blocks".
• Moving it fast across the screen makes the animation really choppy.
• Moving it as fast as possible from one corner of the screen to another makes the window freeze for a split second and then the window moves really quickly over to the cursor's location (it looks smooth at this point but it's hard to tell since it happens really fast)
• As soon as I start a screen recording with wf-recorder (wl-roots native) ALL choppiness is gone and there's just minor micro stuttering/tearing while moving the window around

[vaxerski]

huuuh

can you see if debug:damage_tracking=1 fixes the stutter? (tho don't keep it at that setting after testing god-forbid)

[GrabbenD]

can you see if debug:damage_tracking=1 fixes the stutter? (tho don't keep it at that setting after testing god-forbid)

This made huge difference!

• Moving the window around slowly is butter smooth.
• Moving it between two points at medium speed (like if you were to demo this feature to your friend) is quite smooth. It's very inconsistent between each attempt (even though I try to move the mouse the same way multiple times between the same points on the screen):
  • Usually it's butter smooth for 2 seconds and then it stutters for a split second, it's like it's catching a hiccup.
  • Sometimes it stutters as soon as I start moving it and then it "shakes it off" and becomes smooth.
  • At times there's absolutely no choppiness while moving the window.
  • Occasionally there's micro stutter.
• Moving it really fast from one corner of the screen to another feels like the window is hitting multiple obstacles along the way and breaking free (clearly choppy but it's not as extreme as before).

(For reference, I'm using the performance power governor).

[vaxerski]

Can you (without the damage_tracking opt changed now, you can remove it) turn on debug:damage_blink (warning: epilepsy) and see whether if you move the window quickly the pink highlight follows it correctly?

[vaxerski]

reproduced, found the issue. Fix on the way. 10 month old bug. Nice.

[System-x64]

Finally 😭

[vaxerski]

fixed with 64f35c0e3190f3b56a1c17e81c775966bd0a2251

I was searching in all the wrong places. Murphy's law at its finest.

The source of the issue was invalid bezier calculations for very small $t$ values.

@ sample size 1200:

This was causing the perceived "hiccups"

[NextWork123]

Hello, I tried the latest commit but I'm still experiencing the same issue :/. I have an AMD RX 6600 with Mesa-stable. I also tried setting misc{animate_manual_resizes} to false and true to test, but the result was the same.

https://user-images.githubusercontent.com/46625863/222792947-3346668e-b70e-4602-a1b5-470fb081e291.mp4