chilledfrogs has quit [Quit: connection reset by purr]
talismanick has quit [Read error: Connection reset by peer]
dustinm` has quit [Quit: Leaving]
chilledfrogs has joined #foot
dustinm` has joined #foot
talismanick has joined #foot
ciara_ has quit [Ping timeout: 252 seconds]
ciara has joined #foot
an3223 has quit [Remote host closed the connection]
an3223 has joined #foot
OtzmaVindicus has quit [Remote host closed the connection]
OtzmaVindicus has joined #foot
fitrh has joined #foot
fitrh has quit [Ping timeout: 252 seconds]
mtm has quit [Ping timeout: 252 seconds]
mtm has joined #foot
fitrh has joined #foot
fitrh has quit [Read error: Connection reset by peer]
chimo has quit [Quit: Bye.]
chimo has joined #foot
kchibisov has joined #foot
<kchibisov>
is there some way to measure fps in foot?
<rockorager>
kchibisov: render-timer
<kchibisov>
that's not fps thoug.h
<rockorager>
True, you could calculate theoretical max from it though?
<kchibisov>
it's time to render a _given frame_ iirc, unless it got changed. The time is not consistent though.
<rockorager>
Yeah I think you’d have to collect the stats and do some rolling averages, then get fps from that
<dnkl>
FPS would be capped by the frame rate, so deriving the fps from frame render times is likely not going to give you any faithful numbers
<dnkl>
unless you push very large frames that takes very long time to render...
<kchibisov>
Yeah, unless there's an option to _draw as fast as possible_.
<rockorager>
So it’s probably better to count “dropped” frames (render-time > refresh rate)
<kchibisov>
I mean, if you use only one thread, making it to drop frames is relatively simple.
<kchibisov>
IIRC foot doesn't have separate thread for event loop + renderer?
<kchibisov>
I think it had at some point, but then got reverted for no benifit?
<dnkl>
correct, sort of. Most of the rendering is offloaded to threads, but it's all driven by the main thread. The same thread that also processes events
<dnkl>
at one point, I experimented with offloading PTY reading to a separate thread
<kchibisov>
yeah, we have it separate and a mutex.
<kchibisov>
It does help with some aspects, but if you need to write back, it takes a bit of time.
<dnkl>
the idea being to ensure the pty buffer (kernel side) wasn't filled up (and thus stalling the client application)
<dnkl>
don't think that ever made it to the master branch though
<kchibisov>
I think under load we only able to read around 4095 bytes constantly.
<kchibisov>
and given pty thread to read more somehow makes it slower.
<kchibisov>
Not sure why it happens though, maybe some kernel specific thing.
<dnkl>
sounds similar to what I observed. I could never figure out why pty reading in a separate thread wasn't as fast as I expected it to be
<dnkl>
might be worth revisiting
<kchibisov>
The good thing is that you're more responsive in some cases.
<kchibisov>
As in you don't really block keyboard input.
<dnkl>
yeah, and at this point, I would never accept a patch that sacrificed latency for raw throughput
<kchibisov>
From our testing our infra doesn't matter for latency in most cases.
<kchibisov>
There're like general issues depending on how much time you give pty to read.
<kchibisov>
like I know that our dense_cells benchmark favors foot in terms of latency with sensor at the bottom of the window and overwise at the top.
<kchibisov>
we've tested at the bottom though on the data that yalter published.
<kchibisov>
Have you tried to use wp_presentation to improve latency consistency btw?