> > Right. Just to clarify, performance is currently horrible on PC hardware
> > because we read (memmove) from the framebuffer a lot when dragging windows
> > around. And it seems PC hardware does this really slowly.
>
> All normal graphics hardware has this property. You can't do posted reads
> but you can do posted writes.
We've just switched to redrawing by default, rather than memmoving.
Things are much, much faster on PCs now. I'll post an announcement of
a new version as soon as I can get it uploaded.
> > Right. The idea is just to take clipping and blitting out of the server
> > process and put them in the kernel, to avoid lots of context switches and
> > big complex buffering code.
>
> If your gui system is doing batching of commands this makes no difference.
> Its one of the things X11 showed that was quite suprising.
My understanding is that's certainly true for performance, but not memory
usage and code size/complexity. My board only has 2MB.
I'm sure I'm making lots of mistakes that have been made before, but
that's okay - I'm learning lots from doing it. This is a project I've
wanted to do for ages, and I quit my job so I could spend time on it.
And I really do think we can build something smaller, simpler and faster
than nanogui. We'll see.
> > each, so the complexity of the visible area goes on the stack. Now, how
> > much stack space does the kernel have? :)
>
> Bang...
Also fixed in the new version, the clipping algorithm now uses a stack
structure allocated with kmalloc. Thanks to everyone who provided advice
on this. I now understand very clearly why a dynamically growing stack
area would make dealing with races awful tough. :)
Cheers,
- Ben.
-------------------------------------------------------------------
Ben Williamson benw@pobox.com http://www.pobox.com/~benw/
-
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/