diff options
author | Vito Caputo <vcaputo@pengaru.com> | 2023-10-21 23:55:18 -0700 |
---|---|---|
committer | Vito Caputo <vcaputo@pengaru.com> | 2023-10-22 00:17:07 -0700 |
commit | 5d86941b4ddc8cdde600edeb1e67b2cd85480975 (patch) | |
tree | a4cfc6a6c8b43f4b537bb2e698471462c409f720 /AUTHORS | |
parent | 0c9763f545186cde37a5bdb25bc2843ed3e3003d (diff) |
get_frames,cache_frame: reset yuv blocks once cached
The existing code was assuming every frame would get cached
before the next frame was collected. But that's not strictly
enforced in the current architecture. Sure, the condition
variable is signaled for every frame, but that doesn't guarantee
the cache_frame side will wake up and actually do its thing
before get_frames moves on to the next frame. There's no waiting
for cache_frame to ack the signal before grabbing the next frame.
So in damage-tracking mode (the default when available), there
was a very real potential for lost damage, especially with higher
fps rates.
This commit moves the resetting of the YUV dirty blocks to the
cache_frame side, only after the accumulated dirty blocks have
been processed, immediately prior to releasing yuv_mutex.
As a side effect, the previously get_frames-private
rmdBlocksReset() has moved to rmd_yuv_utils.c and renamed to
rmdYuvBlocksReset(). Some comments have been thrown in flagging
the need to refactor the YUV blocks creation/maintenance - it's
all very ad-hoc as-inherited, I haven't cleaned that up, and it
needs it badly.
Hopefully this fixes some of the lost damage I've been noticing
doing 60-fps captures of programming.
Diffstat (limited to 'AUTHORS')
0 files changed, 0 insertions, 0 deletions