> Stuff like opaque move is entirely server-side, the server is just moving
> a block of pixels around.
Yeah, I wasn't sure what the specifics are with this, which is why I was
trying to read the source to Enlightenment to see how the window manager is
dealing with window exposure, dirty rectangles (for Mac folks), etc...
> 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.
Yeah, I suspect so, but I believe that if the X draw queue would remove all
redraw events until a time period N, or until a mouse up that would allow
for less blocking going with X during moves and resizing. Most of the event
blocking that bothers me comes from big operations like foreground/background
window movement/resizing that perform some kind of time sucking window
updating.
I don't know the specifics of this and you seem to know more about the
internals of this kind of stuff.
Give me a couple of weeks. ;-)
> 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 think you'd see a significant increase in smoothness and responsiveness
if the frequency of redraw events was reduced for this particular operation.
It's a cheap hack that might improve certain things dramatically.
Who knows.
> 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. :-)
Yeah, me too on both of the above points.
;-)
bill
> 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/