Patch that "fixes" compositor-x11

[Bill Spitzak]

Any comments or insight on this problem?

I'm wondering if the slowness of compositor-x11 is a problem that only I 
am encountering? If everybody else is using much faster machines perhaps 
they won't see it, though I think if you run enough clients it should be 
obvious on any machine. Is there something wrong with my version of X or 
xcb? (I am using a stock 11.4 Ubuntu).

I would be concerned that this bug may lead to developers accidentally 
writing code that assumes the "deferred" calls are done after each 
event, rather than after blocks of events.

I have tried equivalent printf statements at other points in the code, 
such as in weston/client/window.c event loop, and they did not fix the 
speed problems. Therefore it appears the print statements must be before 
  whatever is done after x11_compositor_handle_event() returns.

As accurately as I can describe what I am seeing:

  In my current version of weston compositor-x11, the static function 
x11_compositor_next_event() always returns NULL after it returns 
non-null when it is called by x11_compositor_handle_event(). It will do 
this even if there are hundreds of X events queued up from moving the mouse.

  Adding an apparently-useless print statment, *after* the test, causes 
x11_compositor_next_event() to return non-null more than once (up to 15 
in my tests).

  The print statement must be "complex", possibly the requirement is 
that it causes scrolling in the gnome terminal I am sending stdout to.

  Moving the print statement to other apparently-equivalent places in 
the code, in particular to weston/client/window.c, does not fix the problem.