options: add --status-msg-update-rate/--status-msg-update-rate-forced - #18446
options: add --status-msg-update-rate/--status-msg-update-rate-forced#18446MoSal wants to merge 1 commit into
Conversation
|
Partially inspired by seeing this yesterday. |
This is not a problem on any compositor or platform worth using. I don't think mpv needs to have this code |
Do you have a list? jay GPU load drops 50% with my POLARIS GPU too with |
|
The terminal already shouldn't be updating if the contents haven't changed, see
50% of what original value? On anything that supports damage tracking it shouldn't even a measurable increase in GPU use unless there's literally nothing else that would drive that output to update otherwise I guess |
The content does change. It's this alacritty and wezterm are alot more efficient though (single digit % load, 1-2% performance delta). |
|
I'd call that self inflicted pain then, although there may be some mpv bugs to fix here too. avsync property is never stable, so it may need to be throttled in some way to make it more friendly for printing. Simply removing this property from the status line makes it update about half as often as otherwise. *-bitrate properties claim "To make the property more UI friendly, updates to these properties are throttled in a certain way." but I don't see this implemented anywhere actually. video-bitrate is throttled by the fact that it's only updated on keyframes, but audio-bitrate doesn't have any throttling elements. (edit: it's throttled to 500 ms in demux.c) After removing avsync and audio-bitrate from your status line, it already updates no faster than once per second (for time-pos). |
And this will all fall on showing sub-sec fractions. |
Why do you change your status line to show sub second fractions if your goal is minimizing repaint? Explain what the user could be thinking for these two actions to be congruent. |
The point was there are many ways to make the status messages update per frame, which can be a performance foot gun. Going through properties one by one instead of using a simple global configurable higher level solution seems weird. |
On high fps and/or high speed playback scenarios, status message updates from both osd and term can incur a GPU load that is not insignificant, as updates are forced on each frame update. This commit introduces two options that control the update rate. `--status-msg-update-rate` defaults to 20, which matches the 0.05 delay that already existed when there were no forced updates. `--status-msg-update-rate-forced` is set to `no` by default, also to retain old behavior by default. But setting this option to `yes` turns the update rate to a hard limit, unless frame updates happen while paused (e.g. when frame stepping), as getting immediate updated info in that case is the expected behavior. Signed-off-by: Mohammad AlSaleh <CE.Mohammad.AlSaleh@gmail.com>
75e5116 to
690d342
Compare
2 participants
On high fps and/or high speed playback scenarios, status message
updates from both osd and term can incur a GPU load that is not
insignificant, as updates are forced on each frame update.
This commit introduces two options that control the update rate.
--status-msg-update-ratedefaults to 20, which matches the 0.05 delaythat already existed when there were no forced updates.
--status-msg-update-rate-forcedis set tonoby default, also toretain old behavior by default. But setting this option to
yesturnsthe update rate to a hard limit, unless frame updates happen while
paused (e.g. when frame stepping), as getting immediate updated info
in that case is the expected behavior.