raphamorim
`renderer.target-fps` is not working
(PS: issue is very long because I have tried to investigate it and wanted to apologise in beggining only in case it is time waste)
I have tried setting many values, and it seemingly does not work. I tried to search issues and also checked config.md in docs in case there has been any change in behaviour but could not find any
I remember it working so i did a poor man's bisect, and found that it broke between 0.2.20 and 0.2.21 (if I would have read the release notes before trying I would have noticed that 21 had lots of renderer changes and would have just started around it but I am silly).
To reproduce
- download the binaries from github release for 0.2.20, extract rio bin
- set config to some very low value (for example 1 or 2 fps) so it is very easily noticable
- open a rio window, and just type out, or run some command which renders visual things that change (a top window can work assuming it's refresh rate is lower than time between rio redraws as dictated by target-fps, or just print text with echo and see)
(On a side note, I have known this problem for a very long time (release time suggest 3.5 months, and not bothered to report it so it is not a critical bug imo)
My config (renderer bits only, although I have commented all other things out for testing, rest are related to color and fonts only). Platform is arch linux (x86-64). testing was done on files from github releases (deb file to be specific), but i usually use arch package only (which has the same issue).
[renderer]
performance = "Low"
backend = "vulkan"
target-fps = 1
disable-unfocused-render = true
disable-occluded-render = true
level = 1
strategy = "events"
I an not a real programmer, and ~not in a situation to do actual git bisect between the commits (I was free enough to do it, though internet uused to download 3 different rust versions, and approximately 8 gibs of storage usage kinda made me regret doing it)~ I bisected the commits in between and seemingly 163307a2cf83970ba06e1b8833aadd84c590b64c is the first bad commit. there is a possibility that I did run bisect incorrectly, so if anything beyond this point does not make sense, then I am sorry. I am fairly sure that caching the builds of crates in between runs and using sccache should not effect the results (as they work on hashes of files, and assuming they did not change, the resulting code should not change), but just in case it does, I am sorry again. If it helps, I can send/upload the debug builds from last known good commit and first bad in case that helps (maybe a debugger will show better, but I have never used debuggers)(printf only)
163307a2cf83970ba06e1b8833aadd84c590b64c is the first bad commit
commit 163307a2cf83970ba06e1b8833aadd84c590b64c
Author: Raphael Amorim <[email protected]>
Date: Tue Jul 1 16:26:27 2025 -0700
Perf multiscreen (#1189)
* put some logs
* async executor
* wip event
* reduce cpu
* remove logs
* fixup! remove logs
* add Wakeup
frontends/rioterm/src/application.rs | 108 ++++++++++++++++++++++++----------
frontends/rioterm/src/renderer/mod.rs | 5 ++
frontends/rioterm/src/router/mod.rs | 91 ++++++++++++++++++++++++++++
frontends/rioterm/src/screen/mod.rs | 20 +++++--
rio-backend/src/crosswords/mod.rs | 92 ++++++++++++++++++++++++++++-
rio-backend/src/event/mod.rs | 69 ++++++++++++++++++++++
rio-backend/src/performer/mod.rs | 6 +-
sugarloaf/src/sugarloaf.rs | 4 --
8 files changed, 349 insertions(+), 46 deletions(-)
This is roughly where my knowledge limits me, and I can not do much more, but I still did glance at the changes and tried to look for things in https://github.com/raphamorim/rio/commit/163307a2cf83970ba06e1b8833aadd84c590b64c and here are my observations
none of the front ends seem to have anything breaking
-
searched fps keyword and it shows up only in router/mod.rs, where it is seemingly only used in block for logging and tracing purposes, so i do not think that is the bit we are looking for. none other changes in router/mod.rs also seem to do with drawing, and logging in nature only. regardless, all of the changes in file seem to be commented out so should not have any effect.
-
renderer/mod.rs changes are comments only, same is true for screen/mod.rs,
-
changes in application.rs do not seem to breaking, assuming route.request_redraw() (and all the functions it calls for) obey target-fps
now checking backend
-
performer/mod.rs changes seem to be just function name changes, maybe the functions called are different too, so can not call it safe yet
-
I am not 100% sure what github exactly shows by just empy line being highlighted red (i know green highlights are new additions and red is deletions, but for empty lines, there may have been something there, maybe i am just over thinking. line number changes just suggest empty line deletions), and assuming just empty deletions, this should be a purely cosmetic thing, so safe i guess.
-
all changes in crosswords/mod.rs seem to be about damage, finding out if it was partial damage, or full, or just cursor moved, etc, and finally a vector with all damage is shipped. Assuming all these damage calculations would enter the pipeline for checking damage amount and request to be redrawn, and only redrawin part should have a fps limiter, these changes are safe.
-
now only event/mod.rs is left (before checking, I had guessed it would either be events or renderer, and that guess seems correct). half of the changes seem to be just making damage magnitude enum and updating rio event enum for damage and wakeup events. rest is terminal event emitter and that just defines functions to call events for relavent damage type. Assuming renderer obeys fps_limit, change of nature of event should not affect, so this one is safe too?!
That is it from my side. And investigation was not succesfull in finding the problem.
