nanogui@linuxhacker.org

: If clipping is needed, it would be nice to use psd->DrawArea
: to paint only parts of the image, e.g.:
: 

Great idea.  This is exactly how the GdBlit routine works:
If a portion of the blit image needs clipping (that is, if the
image is not wholly contained in one of the clip
rectangles), then the image is intersected with every
clip rectangle in the clip list.  For every non-zero
intersection, the new, smaller rectangle is passed
to the low-level device driver draw routine.
Check out GdBlit, this isn't nearly as bad as
it sounds.  Also, ignore the #ifdefs, I'm right
in the middle of moving Microwindows from
simple rectangle regions to full-blown X-like
regions... 



:   psd->DrawArea(psd, x, y, width, height, pixels,
:                 src_width, src_x, src_y);
: 
: The extra args would make it possible to extract a
: small part of the image/area and paint only that. 

Yes.  Make the arguments in the same order as the
psd->Blit(), so people don't get confused.  Your
low level driver is almost a blitter, and ultimately, 
should be THE blitter.  The currently difference is
that the blitter routines use a new psd->, which is
required to hold the "linelen" which is used to know
how much to add for Y increments...

If you write a low level drawArea that isn't a blitter,
then you get to write about 8 of them, one for every
pixel size.  Go ahead for now, but we'll want to 
rethink blit slightly in the long term.


 This
: may require a change in the way clipping is handled, I'm not
: familiar with the clipping code - but in order to be able to
: go fast, I can't see a way around this functionality.

No change is required in clipping - see GdBlit()


: On a side note; it seems to me there is a thin layer of
: indirection in 'fb.c':  The psd handle has a pointer to
: FB_drawpixel() which only contains a single function
: call to fbprocs->drawpixel in the framebuffer code.
: 
: Can this be avoided?  Couldn't the 'linearXX_init' functions
: just fill in the function pointers for all the functions
: they support directly into the psd handle?
: 

Unfortunately not, I think.  Those extra indirections
were taken original from the BOGL library, where
a SIGUSR signal is sent to the process when the
user switches VT's, and those pointers are all filled
in with fbnull.c no-draw dummy functions.  If this
is removed, you can't switch VT sessions... I know
this is ugly, but I wasn't able to see a way around it,
and figured that Ben Pfaff knew what he was doing
in the first place...



: Before the linearXX_init functions are called, a set of
: default functions can be initialized for the complex
: driver operations that only uses the drawing primitives
: guaranteed to be available to do its work.  This way
: not all drivers have to support all drawing operations.

This is a good idea.  I call those default functions
emulation functions, then we don't have to check for
NULL pointers, the emulation function handles it.
Just make sure that the emulation functions don't
get too large, with duplicated code in devdraw.c.
However, I generally think, that, in graphics, the
more code, the faster it is...



: 
: The reason why I started to look into this is a desire to
: exrtend the framebuffer code to support Area (Surprise!:-)

Cool.  If you add drawArea, then you'll have to extend
the FBENTRY structure.  Or better yet, integrate it
with Blit.  Otherwise, VT switching won't work.

Regards,

Greg