[gstreamer-bugs] [Bug 599885] [gtk examples] unstable behaviour with recent gtk (post csw merge)
bugzilla at gnome.org
Mon Nov 2 23:36:17 PST 2009
GStreamer | gst-plugins-gl | git
--- Comment #2 from Filippo Argiolas <fargiolas at gnome.org> 2009-11-03 08:36:12 CET ---
(In reply to comment #1)
> Do you happen to know how exactly it fails? And would it fail every single time
> for a given program/codepath? (Basically, I wondered if this might be related
> to bug #573694).
Unfortunately I don't know any way to reproduce it reliably (.e. every single
The issue showed in cheese as soon as I upgraded to the new client side gtk+.
The guilty code is the one that sets the xoverlay window from the bus sync
handler (as per gstxoverlay docs).
We, in cheese, set the xoverlay window to GDK_WINDOW_XWINDOW(win->window) where
win is the gdkwindow of a drawing area. This supposes the gdk window has a
native counterpart and after the csw merge that's not safe.
The thing that always puzzled me is that sometimes the window is mapped
correctly and no crash (BadWindow or a generic fatal X11 IO error) happens,
sometimes it happens only when you move the mouse pointer into the overlay
area, sometimes it crashes as soon as the sync handler is called.
Anyway I don't have too much interest of understanding gdk windowing internals,
I'm pretty sure gdk_window_ensure_native definitely fixed the problem in
cheese, it is also a reasonable workaround since we were accessing a native
window so it makes perfectly sense.
I'm almost sure empathy devs did the same thing, and after a quick test I'm
also sure it fixes gst-gl gtk effects "instability".
Regarding the rhythmbox bug, it really feels like the same error I got in
Maybe it is worth putting a note in GstXOverlay docs.
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.
More information about the Gstreamer-bugs