nanogui: Proposition: New functionality for psd->DrawArea
Subject:
Re: Proposition: New functionality for psd->DrawArea
From:
Morten Rolland ####@####.####
Date:
13 Jan 2000 15:38:47 -0000
Message-Id: <387DFC80.292AA6CB@screenmedia.no>
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
