On Tue, Dec 26, 2006 at 03:13:05AM -0500, Michael Lorenz wrote:
> > has a PR been filed about the speed issue?
> 
> Do you have a fix for it? Or, do you have an idea how to fix it?

I have spent a considerable amount of time optimizing framebuffer
routines in Nano-X for a 25MHz embedded platform at work, so I've been
through this before.

the obvious first questions are:

1) how fast is video memory access (read/write)
2) how fast are {main,video} <-> {main,video} copies

the rasops routines in dev/rasops appear to cover the corner cases,
alignment, et al; I'm still not entirely sure why they would be so
horrible unless every video memory access is traversing a VM86 trap or
something similar.  perhaps luke or jared could shed more light on the
code?  (I'm still trying to figure out what I'm looking at and tracing
code paths.)

> There are a few things we could do but those tend have side effects.
> For instance, XFree86 uses a shadow framebuffer to avoid having to
> read from video memory ( which is usually painfully slow ) - gives a
> nice speed boost but costs memory, in vesafb's case kernel memory
> which may or may not be acceptable. If I remember correctly Jared was
> at least looking into supporting it but I'm fairly sure if it's there
> it's not enabled by default.

seems like a shadow framebuffer should be optional; keep a dirty
rectangle, and spawn a kernel thread which does nothing but
lock-and-flush the shadow framebuffer to hardware every X ms.  a shadow
framebuffer might also make it possible to switch between multiple
virtual framebuffers like we do now with multiple text wsconsoles...

> Another thing would be to define a userland interface to switch video
> modes and colour depth, then teach wsfb to use it.

it looks like stubs for the calls are there, but the calls back to VESA
BIOS aren't wired in?

-- 
  Aaron J. Grier | "Not your ordinary poofy goof." | agrier@poofygoof.com
              "silly brewer, saaz are for pils!"  --  virt