nanogui: Thread: Proposition: New functionality for psd->DrawArea

Hello,

Looking through the code for GdArea and GdDrawImage, I figured
it might be a good idea to add some more functionality to
improve speed when clipping has to be performed (or rather,
plan ahead and prepare for optimized drivers that could
help us with clipping).

Today, when the entire area is visible, the psd->DrawArea
could be used (when implemented):

  psd->DrawArea(psd, x, y, width, height, pixels);

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

  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.  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.

It may be better with a separate function call to do this.

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?

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.

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

- Morten

: 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

Greg Haerr wrote:
> 
> : 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.

Great, I'll look into it.

> 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.

Yes... OK.  I'll go ahead for at least the 16-bit version,
and put emulation functions in for the other cases.

> : 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...

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.

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.

This test was only for an totally visible window, ie. no
rectangle-at-a-time-blitting when clipping yet.

> : 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...

Good - I'll put an emulation Area function in, to make it
work for you all before I make a diff.

> Cool.  If you add drawArea, then you'll have to extend
> the FBENTRY structure.

Done, works.

Bye,
- Morten

: 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