avoiding prepare-xwindow-id and gdk threads

[Sebastian Dröge]

On Fr, 2013-11-29 at 13:14 +0200, Dan wrote:
> >> 			gtk.gdk.threads_enter()
> >> 			imagesink.set_xwindow_id(self.movie_window.window.xid)
> >> 			gtk.gdk.threads_leave()
> 
> > You could get the XID of the window before starting the pipeline, store
> > it in some variable and then just set that when you receive the message.
> 
> So the imagesink.set_xwindow_id(somevalue) operation itself is not problematic?

Yes, it's not problematic.

> > The only thing you should not do is to get the XID from the window from
> > the sync bus handler. That's what requires gtk.gdk.threads_enter/leave
> 
> OK, thanks. This puzzles me though. Isn't the window.xid an XWindow
> property which is set at window creation time?

In very old GTK versions it was, but when GTK changed to not create a
separate native window for every widget this became a function. And this
function is creating a new native window and reparenting the widget into
that, so must not be called from a random thread or be protected by the
GDK threading locks.

-- 
Sebastian Dröge <sebastian at centricular.com>
Centricular Ltd - http://www.centricular.com
Expertise, Straight from the Source
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 966 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20131129/5421ad1a/attachment-0001.pgp>