resize-limiter: add additional check for low-hz monitors

[bvr-yr]

Describe your PR, what does it fix/add?

adding 5-6 ms of delay can fix render lag on mouse movement events in some weird combo mouse + 60hz display

should fix #4542
should fix #4669

Is there anything you want to mention? (unchecked code, possible bugs, found problems, breaking compatibility, etc.)

nope

Is it ready for merging, or does it need work?

ready

[vaxerski]

unsure how this is supposed to fix anything tbh

[bvr-yr]

try forcing 60hz refresh rate and move wayland window with bindm, it moves like at 30fps
maybe it's because old hardware but i doubt, cause issue OP have relativly new (tigerlake) intel gpu

this just returns things like they were before 9f20a15 not breaking already done fixes

if there is different solution, sure, but atleast i tried :D

[vaxerski]

christ 60hz is disgusting.

Anyways tried and can't see any issues.

[bvr-yr]

christ 60hz is disgusting.

what can i do it's builtin laptop display :p
imagine how it is like u are on 30hz when moving :D

with plugged 120hz moni its okay rendering on both

Anyways tried and can't see any issues.

well, it might be intel issue, as i'm not only one having this on intel
seen some reports here considering slow gpu wakeups even with forced maxed clock rate. without that forcing animations are noway

[bvr-yr]

i think i found the root cause of the problem

i tried with my old mouse (Logitech g603), which has two modes

• low refresh - 125hz 8ms
• high refresh - 1000hz 1ms

as well as some random wired mouse
all, including my current one sending events every ~8ms

so the timings on 60hz display are:

  7-8ms -> return
15-16ms -> return
23-24ms -> render

while g603 with in high mode sending events every 1-2ms with no render lag

[burein-ita]

Just tested, don't know why but this indeed fixes #4542

[bvr-yr]

i suppose that's because of unlucky timings, returns occurs every 7-8 ms while threshold for 60hz is 16.666666ms, right after second return from limiter but there is too much lag before render happens

this is firing for default non-hi-res input devices on 60hz, and since that might be not the case for the majority of userbase, issue is pretty niche

@vaxerski is adding cfg option viable? or i could think on some another logic in checker

[vaxerski]

hm. I am still unsure what the best course of action is here. Maybe update the cursor pos all the time, and update resize status in a preRender hook?

[bvr-yr]

there's another related issue #4669
i doubt i can do more than adding cfg option, cause it will be a guessing from my side

feel free to close if you are planning to fix it in natural way, i can continue patching if needed

[vaxerski]

I have no idea why that happens, but making the resize inherently more choppy is not the way to do it.

[bvr-yr]

could u please run this snippet from shell

declare -i n=0 total=0
unset time0 time1 m avg
(( ZSH_VERSION )) && m=1.0 || m=1
wev -f wl_pointer:motion | while read -r line; do
	n+=1
	time0=${line%;*}
	time0=${time0#*time: }
	(( delta = time0 - ${time1:-$time0} ))
	(( total += delta < 16 ? delta : avg ))
	(( avg = total * m / n ))
	echo "time:$time0  ms:$delta  avg:$avg"
	time1=${line%;*}
	time1=${time1#*time: }
done

move mouse a bit and paste few last lines

[vaxerski]

finna get a few trojans

time:16728829  ms:8  avg:7.9322033898
time:16728837  ms:8  avg:7.9327731092
time:16728845  ms:8  avg:7.9333333333
time:16728853  ms:8  avg:7.9338842975
time:16728861  ms:8  avg:7.9344262295
time:16728877  ms:16  avg:7.9268292683
time:16728885  ms:8  avg:7.9274193548
time:16728893  ms:8  avg:7.9280000000
time:16728901  ms:8  avg:7.9285714286
time:16728909  ms:8  avg:7.9291338583
time:16728917  ms:8  avg:7.9296875000
time:16728925  ms:8  avg:7.9302325581
time:16728933  ms:8  avg:7.9307692308
time:16728941  ms:8  avg:7.9312977099
time:16728949  ms:8  avg:7.9318181818
time:16728957  ms:8  avg:7.9323308271
time:16728965  ms:8  avg:7.9328358209
time:16728973  ms:8  avg:7.9333333333
time:16728981  ms:8  avg:7.9338235294
time:16728989  ms:8  avg:7.9343065693
time:16728997  ms:8  avg:7.9347826087
time:16729013  ms:16  avg:7.9280575540
time:16729021  ms:8  avg:7.9285714286
time:16729029  ms:8  avg:7.9290780142
time:16729037  ms:8  avg:7.9295774648
time:16729045  ms:8  avg:7.9300699301
time:16729053  ms:8  avg:7.9305555556
time:16729061  ms:8  avg:7.9310344828
time:16729069  ms:8  avg:7.9315068493

[bvr-yr]

nice, u also have shitty mouse

look, can we do like this?
as been reported in #4542 and #4669 issue arises mostly on 60hz
now, if 60hz, there is additional check making it not return 1 extra time and draw instead when input events are too slow

if mouse sends ~1ms (like g603 which i tested), maybe it will skip 1 or 2 returns out of ~15

although, 75hz been mentioned once, i can't see it stuttering, atleast on headless
but if needed, we can just lower bound to 13.0

[vaxerski]

nice, u also have shitty mouse

I don't, I just am not stupid enough to set it to 1000hz. This is a deathadder v2

[vaxerski]

I can't see any stutters even on 1khz

[bvr-yr]

but u won't, it's only 60hz and 7-8ms

if any, 1khz mouse or high rr moni = ok

[bvr-yr]

that's the problem, when both conditions are met:

return
return
draw
return
return
draw

now its

return
draw
return
draw

[vaxerski]

united we stand

[Sinaaaa]

I thought the bad floating window movement performance was on my haswell igpu, but hey this thing seems to have made quite a positive difference. Thank you ~

[bvr-yr]

yeah, it was confusing. initially i thought the same (lulswell too), but people on Tigerlake had same problem, and it is pure luck i have 2 monitors and switchable mouse to catch the problem

glad to help
no more yay --editmenu thank god