It is only used from a single thread

And hmm, this really should use a condition variable too.

That is the same problem as we already had with other object types.
The interface really needs to unload when its owner stops it, not when
the reference counter drops to zero. This fixes a reference dead loop
when an interface yields itself (such as Qt through the view menu) and
a crash if an interface releases itself last (unmapping the running
caller code).

Signed-off-by: Rémi Denis-Courmont <remi@remlab.net>

The macosx drawable variable that used to hold the drawable window reference is splitted up in two variables "drawable-agl" (used by macosx safari/mozilla plugin) and "drawable-gl" (used by macosx interface).

Patch by Erwan10, <brezhoneg1@yahoo.fr>, simplified by /me

Signed-off-by: Rémi Denis-Courmont <remi@remlab.net>

In one case (noted by Erwan Tulou), this also fixes a large leak.

There is _absolutely_ no point in holding an object and releasing it
immediately. Holding an object only makes sense if:
 - the object cannot vanish while calling vlc_object_hold(), and
 - either:
   - the object could have otherwise vanished before
     vlc_object_release(), or
   - there is no way to avoid the (otherwise not needed)
     vlc_object_hold() because it comes from another component.

Conversely, it makes no sense to hold an object, if:
 - it could vanish already while calling hold (race condition)
   -> this is *invalid* and might crash,
 - there is already a valid reference to the object throughout.

I don't know in which case that code was, but the popup menu definitely
does invalid object access in some cases. For instance:
 - start playing a single video,
 - seek to a few seconds before the end,
 - open the popup menu, go to video / deinterlace,
 - wait for the video to finish and the playlist to stop,
 - click on "X" from the deinterlace submenu.
Oops.

Signed-off-by: Rémi Denis-Courmont <remi@remlab.net>