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.
_______________________________________________
wayland-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
