Fix frame handoff race and eliminate redundant copies

[xav-ie]

Summary

• Replaces inputBGRA.empty() checks with an std::atomic<bool> newFrameAvailable flag, fixing a data race where the tick thread could read inputBGRA outside the mutex in enhance-filter.cpp
• Uses cv::swap() instead of clone() in both background-filter.cpp and enhance-filter.cpp for O(1) frame handoff from render thread to tick thread
• Uses copyTo() instead of clone() in obs-utils.cpp so the destination buffer is reused when dimensions haven't changed, avoiding a heap allocation per frame

Benchmark results (300 iterations, best of 3 runs)

Step	Median (µs/frame)	Change
Before (clone + empty() check)	1127.7	—
After (swap + copyTo + atomic flag)	675.9	−40%

Pull Request Checklist

Please read our latest CONTRIBUTING.md.

• I have read the latest CONTRIBUTING.md.
• I have acknowledged the licensing and patent grant policy.
• I have included the required license headers.
• I am confident with my code integrity.
• I have signed off and verified all my commits.

[royshil]

I remember vaguely that we had used swap in the past and reversed back to clone... iirc the reason was that it ran into mem alloc issues

Time savings are great but we can't regress functionality or introduce bugs

[xav-ie]

Thanks for the review! I searched the history and couldn't find evidence of cv::swap being used before:

$ git log origin/main -S "cv::swap" --oneline -- src/
(no results)

You might be thinking of PR #225, which proposed replacing cv::Mat with raw uint8_t buffers + memcpy for inter-thread communication — that was closed in favor of the mutex + clone() approach in PR #224.

Our cv::swap here is safe under the existing mutex:

• Render thread (obs-utils.cpp): holds inputBGRALock, calls copyTo() which writes into tf->inputBGRA's buffer
• Tick thread (background-filter.cpp): holds inputBGRALock, calls cv::swap(imageBGRA, tf->inputBGRA) which just swaps the Mat headers (pointer, size, refcount) in O(1) — no allocation, no copy
• After the swap, the tick thread exclusively owns the pixel data and tf->inputBGRA is left empty
• So the only allocation that ever happens is when frame dimensions change, which is the same as clone() but without re-allocating every single frame.

Correction: Since swap empties tf->inputBGRA, copyTo allocates fresh on the next render — so this halves allocations and copies (2 per cycle → 1), not eliminates them. That's where the ~40% benchmark improvement comes from.

[umireon]

#224 and #225 are my PRs. Thanks for contributing stability!

[umireon]

Working on the CONTRIBUTING.md now. Sorry but wait a moment, please.

[royshil]

i think the changes check out. curious to see it in action

[umireon]

@xav-ie I've added checklist to your description. Feel free to ask us for question, it is added to this project just now.

Checklist added

[umireon]

Licensing works are almost completed. #797

[umireon]

@xav-ie #797 merged. Please update your branches and let me help you align with our guidelines.

[royshil]

@xav-ie are you still working o n this as a draft or want to make it a legit pull requets?

[umireon]

The following code:

		if (!tf->newFrameAvailable) {
			return;
		}
		imageBGRA = tf->inputBGRA.clone();
		cv::swap(imageBGRA, tf->inputBGRA);
		tf->newFrameAvailable = false;

should be like:

		if (tf->newFrameAvailable.exchange(false, std::memory_order_acq_rel)) {
			cv::swap(imageBGRA, tf->inputBGRA);
		}

for better performance with appropriate memory barrier.

[umireon]

Suggested change

	if (!tf->newFrameAvailable) {
	return;
	}
	cv::swap(imageBGRA, tf->inputBGRA);
	tf->newFrameAvailable = false;
	if (!tf->newFrameAvailable.exchange(false, std::memory_order_acq_rel)) {
	cv::swap(imageBGRA, tf->inputBGRA);
	}