summaryrefslogtreecommitdiff
path: root/AUTHORS
diff options
context:
space:
mode:
authorVito Caputo <vcaputo@pengaru.com>2023-10-21 23:55:18 -0700
committerVito Caputo <vcaputo@pengaru.com>2023-10-22 00:17:07 -0700
commit5d86941b4ddc8cdde600edeb1e67b2cd85480975 (patch)
treea4cfc6a6c8b43f4b537bb2e698471462c409f720 /AUTHORS
parent0c9763f545186cde37a5bdb25bc2843ed3e3003d (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
© All Rights Reserved