sub: uglify OSD code path with locking

Do two things:
1. add locking to struct osd_state
2. make struct osd_state opaque

While 1. is somewhat simple, 2. is quite horrible. Lots of code accesses
lots of osd_state (and osd_object) members. To make sure everything is
accessed synchronously, I prefer making osd_state opaque, even if it
means adding pretty dumb accessors.

All of this is meant to allow running VO in their own threads.
Eventually, VOs will request OSD on their own, which means osd_state
will be accessed from foreign threads.

1 files changed, 4 insertions, 5 deletions

diff --git a/player/playloop.c b/player/playloop.c
index 95e9a9c5a4..167a0722a2 100644
--- a/player/playloop.c
+++ b/player/playloop.c
@@ -136,7 +136,7 @@ static void draw_osd(struct MPContext *mpctx)
 {
     struct vo *vo = mpctx->video_out;
 
-    mpctx->osd->vo_pts = mpctx->video_pts;
+    osd_set_vo_pts(mpctx->osd, mpctx->video_pts);
     vo_draw_osd(vo, mpctx->osd);
 }
 
@@ -646,10 +646,9 @@ static bool handle_osd_redraw(struct MPContext *mpctx)
 {
     if (!mpctx->video_out || !mpctx->video_out->config_ok)
         return false;
-    bool want_redraw = vo_get_want_redraw(mpctx->video_out);
-    if (mpctx->video_out->driver->draw_osd)
-        want_redraw |= mpctx->osd->want_redraw;
-    mpctx->osd->want_redraw = false;
+    bool want_redraw = vo_get_want_redraw(mpctx->video_out) |
+                        (osd_query_and_reset_want_redraw(mpctx->osd) &&
+                         mpctx->video_out->driver->draw_osd);
     if (want_redraw) {
         if (redraw_osd(mpctx))
             return true;