obs-studio
obs-studio copied to clipboard
obsproject
UI: Fill audio meter background each update (#9842)
Description
Since the audio mixer widget is marked as being opaque it is necessary to draw all of it's pixels in the drawing region. Pixels not being drawn will leave transparent pixels (on Wayland at least) causing undesired effects.
Previously, the background was not filled when only the meters were repainted. Since the meters don't paint the complete region (spacing, padding etc.) some pixels in the region ended up not being painted.
Motivation and Context
Addressing https://github.com/obsproject/obs-studio/issues/9824
How Has This Been Tested?
Locally run on GNOME/Wayland which was affected by the bug. After applied fix, the audio mixer looks correctly.
Hopefully this does not regress other platforms..
Types of changes
- Bug fix (non-breaking change which fixes an issue)
Checklist:
- [x] My code has been run through clang-format.
- [x] I have read the contributing document.
- [x] My code is not on the master branch.
- [x] The code has been tested.
- [x] All commit messages are properly formatted and commits squashed where appropriate.
- [x] I have included updates to all appropriate documentation.
I feel like the audio mixer painting was done in a very particular way due to it being very heavy on macOS. @PatTheMav ?
Yeah this PR needs to be checked whether it introduces a performance regression on Retina screens, especially with 120Hz ProMotion displays.
Without checking the power impact of the change (suggesting that the CPU clocks are increased) the CPU time spent on the volume meters is not significantly different with this change applied. Still the second heaviest stack in the program at idle use, but that's also the case without the change.
- See Improve scaling of audio meter (issue 3915) #5233 for some context behind the current behaviour.
In particular, I was indeed thinking of #5233 but also commit https://github.com/obsproject/obs-studio/commit/f4f2d383b1f234dc231ca0dc2804d8ba5c69635e, the latter of which specifically called out performance issues when we changed the volume meters from updating at 30Hz to 60Hz.
Without checking the power impact of the change (suggesting that the CPU clocks are increased) the CPU time spent on the volume meters is not significantly different with this change applied. Still the second heaviest stack in the program at idle use, but that's also the case without the change.
If there are no noticeable performance regressions though, it sounds like this should be fine?