Closed System-x64 closed 1 year ago
verify that fact with hyprctl version
@vaxerski done. i think we compiled on that commit #51ce3dd
huh. Can anyone else confirm it's still an issue?
fixed with 64f35c0
Most impressive that you managed to find this edge case, well done :)
huh. Can anyone else confirm it's still an issue?
I tried your fix https://github.com/hyprwm/Hyprland/commit/64f35c0e3190f3b56a1c17e81c775966bd0a2251 and I removed debug:damage_tracking
from my config. Here's my observations:
misc:animate_mouse_windowdragging
it feels even smoother than before so that's a win.With OBS and wlrobs plugin I'm able to actually record this issue! Here's a demo (all stuttering/choppiness in the video is what's actually happening on the screen):
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?
I jumped a few commits forward to https://github.com/hyprwm/Hyprland/commit/fe007fd36a050103c7953bf5ba68d6ba7187b6e1 and enabled debug:damage_blink
(while debug:damage_tracking
is still removed). Had to keep it super short due to file size limit. Also, for some reason the damage_blink disappears towards the end of the video, this is a bug in OBS:
Here's my config file, it's mostly default for testing purposes:
If I now disable misc:animate_mouse_windowdragging it feels even smoother than before so that's a win.
placebo, didnt have anything to do with this
It didn't resolve the original issue.
reeee it did for me and now I can't repro againnnnn
Curves are perfectly fine now (1200 samples)
can't see what's going wrong.
placebo, didnt have anything to do with this
My eyes are playing tricks on me after playing around with this for too long 😅
reeee it did for me and now I can't repro againnnnn
Flying blind 💀
I tried various monitor configurations to see if that could be the issue but nope (also, just one monitor is plugged in to DP-3 while trying this):
10 bit + default scaling (0x0,1) with:
3840x1600@119.982002
(hyprctl monitors
recommendation)3840x1600@119
3840x1600@120
default scaling (0x0,1) with:
3840x1600@119.982002
3840x1600@119
3840x1600@120
I also tried a different 8bit monitor. Default scaling (0x0,1):
1920x1080@60
Let us know if there's anything that we can try!
Also confirmed that this doesn't fix the issue either:
misc {
vfr = 0
}
Flying blind :skull:
wat
I tried various monitor configurations to see if that could be the issue but nope
turn on the debug overlay and check the var
on animation ticking - if it's not higher than your avg frametime, it should be fine.
curves we know are fine
you say DT on monitor solves the issue partially - frame scheduling is off? but then vfr should fix that
that leaves damage tracking to be the culprit, but if that was the case we'd see "tearing"-ish artifacts and furthermore that should then affect more than just resizing manually but all animations. Besides, it should be reproducible.
wtf.
It seems to be gone. The animations still aren't as smooth as they could be, tho.
Nice. I accidentally committed that patch yesterday. Can anyone else test if the stuttering still persists? If like 3 people say it's fixed I'll close.
i can confirm, is fixed thanks.
on setting
misc{animate_manual_resizes}
to true, the window gets a weird lag or idk what to call ithttps://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