nanogui: Screen update methods
Subject:
Re: [nanogui] Re: Screen update methods
From:
"Greg Haerr" ####@####.####
Date:
27 May 2007 00:36:41 +0100
Message-Id: <036701c79fee$a3749d70$2f01a8c0@HaydenLake>
> What's really bothering me is why are the lowlevel driver called to write
> any data
to the framebuffer when it's being called to draw them on a pixmap. I seem
to be missing something here and I'm hoping someone could tell me what that
is.
In terms of drawing, the framebuffer and a pixmap are
*exactly* the same, just a different start memory address.
You're thinking that a framebuffer is something different or
special, when its just a block of memory to draw into,
just like a pixmap is.
The nano-X low level drivers all draw into a memory block,
and have no idea what the "block" really is. And they don't
need to, since the drawing requires exactly the same code.
> I only expect the blit function to be called when I explicitly copy data
> from the offscreen pixmap to the active window. Is this not true?
There is no such thing as an "active window". There are only
draw rectangle memory locations with a clipping set. The
draw locations can be the address of the actual framebuffer,
or any allocated pixmap, of course.
When drawing pixel-by-pixel, or line-by-line, the driver-
level drawpixel or drawline (horz or vert) routines are
called. Rectangle fills currently use repeat horz drawline.
When copying a bitmap or memory, the blit routine is called.
There are not multiple options (routines) to determine when
drawing, instead set driver entrypoint(s) are called to
effect the required drawing.
> Any drawing I've done I've done on a pixmap
so I can do one block copy to the framebuffer.
Yes. Unless you originally filled the pixmap
from another image, low-level pixel/line routines were
called to draw the pixmap, then the blit driver routine
was used to copy it (to the framebuffer or another
pixmap, they're just memory addresses).
Hope this helps.
Regards,
Greg
