GNOME Bugzilla – Bug 619516
[perf] Add glx.swapComplete event
Last modified: 2010-05-26 19:39:08 UTC
Add an event when we receive an event on buffer swap completion; we'll only get this if Clutter is using the INTEL_swap_event GLX extension, but it's useful to see the actual timing of video frames. The recorded event includes the actual timestamp of the swap, since we are given that in the GLX event - on my system it tends to be consistently 80-100us before we log the event, but if something was going wrong in event handling (too much synchronous work), then that could could show up as a longer delay.
Created attachment 161863 [details] [review] [perf] Add glx.swapComplete event
Review of attachment 161863 [details] [review]: ::: src/gnome-shell-plugin.c @@ +470,3 @@ XEvent *xev) { +#ifdef GLX_INTEL_swap_event Wouldn't it make sense to check whether the extension is present at all too? (Of course only once and not for each event).
Hmm. Yes, and no. GLX event IDs are permanently allocated, so if we get an event with event_type == (glx event base> + 15) that's a swap event, always. *Unless* glx_event_base + 15 is outside of the range of event ID's that the GLX X extension has reserved. It's unclear to me the exact history of what range of events were being reserved, but it's certainly conceptually possible that the server might not be reserving that many events for an older server that doesn't support INTEL_swap_event. So, probably, yes, we should check for the extension.
Created attachment 162038 [details] [review] [perf] Add glx.swapComplete event This version checks for the extension, and also ignores swap events with a ust (system time) field of 0 - this isn't allowed by the spec, and I was seeing events sent that way with a radeon driver version which has a partial/buggy implementation of INTEL_swap_complete
Review of attachment 162038 [details] [review]: OK, this make sense and doing the check does not really hurt anyway.
Attachment 162038 [details] pushed as 0eeb627 - [perf] Add glx.swapComplete event