From 67689ff6b42173b72bffecf23de3507e3ab605b0 Mon Sep 17 00:00:00 2001
From: wm4 <wm4@nowhere>
Date: Fri, 20 Apr 2018 19:26:04 +0200
Subject: client API: preparations for allowing render API to use DR etc.

DR (letting the decoder allocate texture memory) requires running the
allocation on the render thread. This is rather hard with the render
API, because the user controls this thread and when it's entered. It was
not possible until now.

This commit adds a bunch of infrastructure to make this possible. We add
a new optional mode (MPV_RENDER_PARAM_ADVANCED_CONTROL) which basically
lets the user's render thread and libmpv agree how this should be done.

Misuse would lead to deadlocks. To make this less likely, strictly
document thread safety/locking issues. In particular, document which
libmpv functions can be called without issues. (The rest has to be
assumed unsafe.)

The worst issue is destruction of the render context while video is
still active. To avoid certain unintended recursive locks (i.e.
deadlocks, unless we'd make the locks recursive), make the update
callback lock separate. Make "killing" the video chain asynchronous, so
we can do extra work while video is being destroyed.

Because losing wakeups is a big deal, setting the update callback now
triggers a wakeup. (It would have been better if the wakeup callback
were a parameter to mpv_render_context_create(), but too late.)

This commit does not add DR yet; the following commit does this.
---
 libmpv/mpv.def | 1 +
 1 file changed, 1 insertion(+)

(limited to 'libmpv/mpv.def')

diff --git a/libmpv/mpv.def b/libmpv/mpv.def
index 1d828f4b2b..efbf713622 100644
--- a/libmpv/mpv.def
+++ b/libmpv/mpv.def
@@ -38,6 +38,7 @@ mpv_render_context_render
 mpv_render_context_report_swap
 mpv_render_context_set_parameter
 mpv_render_context_set_update_callback
+mpv_render_context_update
 mpv_request_event
 mpv_request_log_messages
 mpv_resume
-- 
cgit v1.2.3

