nanogui@linuxhacker.org

: If we can assume the 'psd' data structures don't get copied
: around by the application, the driver can have its own 'psd'
: pointer that it uses to update all the drawing function
: pointers on task switches?
: 
: This may not be very elegant, but the extra layer kind of
: feels wrong --- at least for pixel and line draw operations
: that don't do much work for a single call.

Morten - that's a good idea.  Why didn't I think of it?
Oh - that's right, we didn't have psd's until off-screen
blitting, and by that time, I already had FBENTRYs.

However, let's not change it yet, since the X Window
screen driver takes advantage of some of this.  There's 
an additional issue: the off-screen memory bitmaps
use a copy of the screen psd, and this one wouldn't
be switched out when VT switches occurs.  I'll
think about getting this changed, since it does
involve an extra procedure call, and that's slow.

BTW - if you want SPEED, make sure that you
#define NDEBUG in your fblinX.c files, that
will remove the millions of asserts() that slows
it down considerably.




: 
: I have implemented a 16-bit Area function that uses memcpy,
: and the GdArea call was 6x faster for an image that
: translates to a lot of long lines in the old code.
: With 16-bit jpeg natural images this number will probably
: be much higer as the number of shorter line segments
: increases.
: 

That sounds about right.  It's amazing how much faster
memcpy is that for looping...



: This test was only for an totally visible window, ie. no
: rectangle-at-a-time-blitting when clipping yet.
:
I think you'll find that chopping the clipped image into 
cliprect-sized pieces will not slow down the drawing
much at all.  This is the case with the current blit code.

Regards,

Greg