After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 595427 - avoid x event thread if not needed
avoid x event thread if not needed
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
git master
Other Linux
: Normal enhancement
: 0.10.26
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2009-09-17 06:38 UTC by Stefan Sauer (gstreamer, gtkdoc dev)
Modified: 2009-10-07 15:01 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
make the event thread conditial (4.27 KB, patch)
2009-09-17 06:39 UTC, Stefan Sauer (gstreamer, gtkdoc dev)
none Details | Review
make the event thread conditial (4.32 KB, patch)
2009-09-30 13:47 UTC, Stefan Sauer (gstreamer, gtkdoc dev)
none Details | Review

Description Stefan Sauer (gstreamer, gtkdoc dev) 2009-09-17 06:38:18 UTC
The attached patch starts/stops the event thread in xvimagesink as needed. This reduces context switches. Right now the thread polls the event 20 times a second.

I have this applied in my system and see no regression so far. Would be nice to get a review and some testing.
Comment 1 Stefan Sauer (gstreamer, gtkdoc dev) 2009-09-17 06:39:22 UTC
Created attachment 143320 [details] [review]
make the event thread conditial
Comment 2 Sebastian Dröge (slomo) 2009-09-22 06:29:33 UTC
Looks good but those GST_WARNINGs should really be GST_DEBUG, right? :)
Comment 3 Sebastian Dröge (slomo) 2009-09-22 06:30:21 UTC
Also, isn't it possible to let the X event thread block until an event happens or until some timeout happens? Polling is never a good idea :)
Comment 4 Stefan Sauer (gstreamer, gtkdoc dev) 2009-09-30 13:47:44 UTC
Created attachment 144398 [details] [review]
make the event thread conditial

GST_WARNING -> GST_DEBUG_OBJECT

Regarding the polling. I am not an x-exper, but it looks like I could use
XWindowEvent instead of XCheckWindowEvent. This needs rewriting the while loops in gst_xvimagesink_handle_xevents() so that there is a single loop.

[1] http://tronche.com/gui/x/xlib/event-handling/manipulating-event-queue/XWindowEvent.html
[2] http://tronche.com/gui/x/xlib/event-handling/manipulating-event-queue/XCheckWindowEvent.html
Comment 5 Jan Schmidt 2009-09-30 15:13:56 UTC
The reason it uses XWindowCheckEvent is precisely to avoid blocking.

The thread putting buffers on the screen is trying to use that same X display connection. It will be stalled waiting for the input thread whenever the input thread is holding the xlock.

It might be possible instead to poll/select on the X display file descriptor (XConnectionNumber()) and avoid using a timeout. It probably needs to be done in a way that uses GstPoll(), and disables it when the display thread is doing any X operations.
Comment 6 Stefan Sauer (gstreamer, gtkdoc dev) 2009-10-01 13:08:44 UTC
Jan, thanks for the info. Do you see any issue with the patch as it is. I would prefer to address the polling as a separate patch if at all.
Comment 7 Jan Schmidt 2009-10-01 13:20:17 UTC
No, the current patch to entirely enable/disable the polling thread seems like a good idea.
Comment 8 Stefan Sauer (gstreamer, gtkdoc dev) 2009-10-07 09:02:41 UTC
I am pushing this now to get some wider testing.

commit 99b4483b8cc2584617131a468d38556ef0db154b
Author: Stefan Kost <ensonic@users.sf.net>
Date:   Tue Sep 15 15:26:06 2009 +0300

    xvimagesink: only start event thread if needed
    
    The event thread is doing 20 wakeups per second to poll the events. If one runs
    xvimagesink with handle-events=false and handle-expose=false then we can avoid
    the extra thread.
Comment 9 Tim-Philipp Müller 2009-10-07 09:08:31 UTC
Shouldn't this also be fixed in ximagesink then?
Comment 10 Stefan Sauer (gstreamer, gtkdoc dev) 2009-10-07 10:58:37 UTC
Good catch and probably in vdpau and other derivatives too. I'll fix it in ximagesink as well.
Comment 11 Stefan Sauer (gstreamer, gtkdoc dev) 2009-10-07 15:01:14 UTC
Done for ximagesink too.