Window move definitely shouldn't cause redraws, resize *might* for some
window managers (but doesn't for mine). This may well be an issue with
your window manager. I can't get any noticeable delay with WindowMaker, a
Gnome app, and a P233, swirling my mouse like mad, using opaque move.
Perhaps I misunderstand what you mean though.
In any case, X isn't doing the redraws - the app is (well, the app is
determining when they happen, though the X server does the actual placing
of pixels onscreen). And in general Gtk only does them a single time (once
no other events are pending).
Stuff like opaque move is entirely server-side, the server is just moving
a block of pixels around.
However, it is basically true that X/Linux has slower graphics than BeOS,
no doubt about that. I think it's more the additional abstraction of the X
architecture, and the original, intended purpose of the kernel.
We don't have to be as fast as BeOS though - just fast enough to work
fine for 99% of applications. So we'll get there, I would think.
> Yeah, I agree. the GTK folks are doing something like that, but I'm not
> sure how variuos X internals are going to deal with its' event queue on
> top of another event queue architecture.
I don't predict problems - Gtk has no new event queue architecture really.
It trivially preprocesses X events, but the architecture is the same. Gtk
adds additional layers (an event loop and the widget/signal system) which
build on and depend on the event queue from Gdk/Xlib. So I think it will
work fine.
Also, consider that rendering is basically multithreaded already; if I
call XDrawLine(), then that sends only a few bytes to the X server, and
immediately returns; the server does the actual drawing in a separate
process, totally asynchronously. If you have two threads in the client,
you don't gain that much - the "engine" thread still has to tell the
"display" thread to refresh, but the "display" thread isn't doing
anything, just handing off to the X server. The "display" thread is useful
if the app does significant computation for rendering, but that's not true
for Gtk and most apps written with it. It just isn't that expensive on the
client side. The obvious exceptions are the Gimp, games, and that sort of
thing.
I've heard the XFree people are working on making the server itself more
multithreaded, but I don't know much about it.
Anyway, it will work out in the end. :-)
Havoc
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/