nanogui: Thread: Bitblt proposal (was: Re: bogl routines)

Greg Haerr ####@####.#### writes:
   [...some good points...]

enum
  {
     BOGL_ROP_NOP,
     BOGL_ROP_AND,
     BOGL_ROP_OR,
     BOGL_ROP_XOR,
  };

/* Copy a block of pixels from (SX,SY)-(SX+W,SY+H) in SRC to
   (DX,DY)+(DX+W,DY+H) in DEST, applying raster operation ROP.  DST
   and SRC may be bitmaps created with bogl_create_bitmap(), or they
   may be null pointers, representing the screen image.  */
void bogl_bitblt (struct bogl_bitmap *dst, int dx, int dy,
                  struct bogl_bitmap *src, int sx, int sy,
                  int w, int h, int rop);

/* Dynamically allocate a bitmap of size (W,H).  Initialize all the
   pixels in the bitmap to background color BG; if BG == -1, leave
   them undefined.  Returns a pointer to the created bitmap if
   successful; otherwise, returns a null pointer. */
struct bogl_bitmap *bogl_create_bitmap (int w, int h, int bg);

Okay, this still leaves masking.  We could add a mask parameter, I
suppose:

/* Copy a block of pixels from (SX,SY)-(SX+W,SY+H) in SRC to
   (DX,DY)+(DX+W,DY+H) in DEST, applying raster operation ROP.  DST
   and SRC may be bitmaps created with bogl_create_bitmap(), or they
   may be null pointers, representing the screen image.  If MASK is
   non-null, then it must be a 1-bit-depth mask of size (W,H)
   specifying which pixels in SRC should be copied.  Each row in MASK
   must be padded on the right to a 32-bit multiple in size. */
void bogl_bitblt (struct bogl_bitmap *dst, int dx, int dy,
                  struct bogl_bitmap *src, int sx, int sy,
                  int w, int h, int rop, void *mask);

Already I'm saying ``Ugh'' to myself when I think about actually
implementing this.  Do we need even more than that?
----------------------------------------------------------------------
An evil thought just occurred to me, actually.  With most visuals (not
vga16) we can easily add a `struct bogl_bitmap *' parameter to all the
bogl_*() functions, which could be a bitmap or NULL to represent the
screen.  Then we'd be able to support drawing on off-screen bitmaps
just as easily as with the screen.

Comments?

-- 
"Let others praise ancient times; I am glad I was born in these."
--Ovid (43 BC-18 AD)

Ben Pfaff ####@####.#### writes:
   [...bitblt proposal...]

I haven't seen any replies on this.  Either that means that my email
is screwed up again, or no one made any comments.

Should I take this as initial assent to my proposal?  If so, then I'll
get started on it sometime this week, probably implementing vga16 and
cfb8 as a test case.

> An evil thought just occurred to me, actually.  With most visuals (not
> vga16) we can easily add a `struct bogl_bitmap *' parameter to all the
> bogl_*() functions, which could be a bitmap or NULL to represent the
> screen.  Then we'd be able to support drawing on off-screen bitmaps
> just as easily as with the screen.
> 
> Comments?
> 

	Your evil thought is a very good one.  Having just implemented
bitmaps over the weekend, I've been thinking about off-screen drawing the
same way many other graphics systems do it:  The screen is just another
bitmap.  All graphics draw functions work on bitmaps, rather than screens.
Right now, the graphics functions work by calling the device api to draw.

A useful architecture change would be to have all the mid-level graphics functions
work on a "bitmap structure" which would include function pointers for the draw functions.
The drawing functions are organized according to their ability to draw on 1 plane 8-bit
pixels, 4-plane 4-bit pixels, etc.  In this way, drawing to the screen is a special
case of drawing to an in-core bitmap.

For a really cool implmentation of these ideas, refer to the great allegro link
that Alex sent to this list last week.  There is much to be learned by studying these
sources, which I did over the weekend.

Greg

> Okay, this still leaves masking.  We could add a mask parameter, I
> suppose:
> 
> /* Copy a block of pixels from (SX,SY)-(SX+W,SY+H) in SRC to
>    (DX,DY)+(DX+W,DY+H) in DEST, applying raster operation ROP.  DST
>    and SRC may be bitmaps created with bogl_create_bitmap(), or they
>    may be null pointers, representing the screen image.  If MASK is
>    non-null, then it must be a 1-bit-depth mask of size (W,H)
>    specifying which pixels in SRC should be copied.  Each row in MASK
>    must be padded on the right to a 32-bit multiple in size. */
> void bogl_bitblt (struct bogl_bitmap *dst, int dx, int dy,
>                   struct bogl_bitmap *src, int sx, int sy,
>                   int w, int h, int rop, void *mask);
> 
> Already I'm saying ``Ugh'' to myself when I think about actually
> implementing this.  Do we need even more than that?
> 

If it makes you feel any better, the Win32 bitblt function takes *nine* parameters:

	BitBlt(hdcDest, xDest, yDest, wDest, hDest, hdcSrc, xSrc, ySrc, dwOpcode);

the hdc parms are handles to device context's, which are either the screen or a
selected off-screen (memory) bitmap.

You're actually on the right track...

Greg

On 17 May 1999, Ben Pfaff wrote:
> Ben Pfaff ####@####.#### writes:
>    [...bitblt proposal...]
> 
> Should I take this as initial assent to my proposal?  If so, then I'll
> get started on it sometime this week, probably implementing vga16 and
> cfb8 as a test case.

Did you get anywhere with this Ben?

How close are the variable bit width drivers to being usable (I'm assuming
they're the bogl-tcfb and bogl-pcfb drivers)? Also, am I right in thinking
that the VGA16 will still require a separate driver due to it's non-linear
architecture (which would also seem to be why GGI won't work on top of
it)?

--------------- Linux- the choice of a GNU generation. --------------
: Alex Holden (M1CJD)- Caver, Programmer, Land Rover nut, Radio Ham :
-------------------- http://www.linuxhacker.org/ --------------------

Alex Holden ####@####.#### writes:

   On 17 May 1999, Ben Pfaff wrote:
   > Ben Pfaff ####@####.#### writes:
   >    [...bitblt proposal...]
   > 
   > Should I take this as initial assent to my proposal?  If so, then I'll
   > get started on it sometime this week, probably implementing vga16 and
   > cfb8 as a test case.

   Did you get anywhere with this Ben?

Not yet.  Maybe tomorrow or Saturday.  I simply haven't worked on it yet.

   How close are the variable bit width drivers to being usable (I'm assuming
   they're the bogl-tcfb and bogl-pcfb drivers)?

They don't work now?  I haven't tested them (they're by ####@####.####
not me), but I can now that I have matroxfb set up on my main machine.

   Also, am I right in thinking that the VGA16 will still require a
   separate driver due to it's non-linear architecture (which would
   also seem to be why GGI won't work on top of it)?

Yes.  I'm not sure what pixmap format I'll use for it yet; probably
interleaved planes.  I think that's the most hardware-efficient way to
blit the bits.

On 20 May 1999, Ben Pfaff wrote:
>    How close are the variable bit width drivers to being usable (I'm assuming
>    they're the bogl-tcfb and bogl-pcfb drivers)?
> They don't work now?  I haven't tested them (they're by ####@####.####
> not me), but I can now that I have matroxfb set up on my main machine.

I hadn't tried them yet; I somehow got the idea that they were a work in
progress. I'll have a go with them this afternoon.

--------------- Linux- the choice of a GNU generation. --------------
: Alex Holden (M1CJD)- Caver, Programmer, Land Rover nut, Radio Ham :
-------------------- http://www.linuxhacker.org/ --------------------

On Thu, 20 May 1999, Alex Holden wrote:
> On 20 May 1999, Ben Pfaff wrote:
> >    How close are the variable bit width drivers to being usable (I'm assuming
> >    they're the bogl-tcfb and bogl-pcfb drivers)?
> > They don't work now?  I haven't tested them (they're by ####@####.####
> > not me), but I can now that I have matroxfb set up on my main machine.
> I hadn't tried them yet; I somehow got the idea that they were a work in
> progress. I'll have a go with them this afternoon.

I can't try them on my PC due to it having a crap graphics card (I'll
probably buy a new one soon because it's bugging me), but the results on
the NetWinder were:

8bpp works fine.
16bpp silently fails (the initialise call fails).
24bpp fails with:
bogl-cfb.c:54: memset_var: Assertion `(((unsigned int)dst * 8) % b) == 0' failed.
32bpp seems not to work at all on the NetWinder.

Another thing I noticed is that the FBIOPAN_DISPLAY ioctl always fails
on the NetWinder (I think the hardware doesn't support it), so you should
probably remove the test for the return value, as it causes bogl to die
when the ioctl call returns -1.

--------------- Linux- the choice of a GNU generation. --------------
: Alex Holden (M1CJD)- Caver, Programmer, Land Rover nut, Radio Ham :
-------------------- http://www.linuxhacker.org/ --------------------

On Thursday, May 20, 1999 7:06 AM, Alex Holden ####@####.#### wrote:
> On 20 May 1999, Ben Pfaff wrote:
> >    How close are the variable bit width drivers to being usable (I'm assuming
> >    they're the bogl-tcfb and bogl-pcfb drivers)?
> > They don't work now?  I haven't tested them (they're by ####@####.####
> > not me), but I can now that I have matroxfb set up on my main machine.
> 
> I hadn't tried them yet; I somehow got the idea that they were a work in
> progress. I'll have a go with them this afternoon.
> 


The addition of a single readpixel entry point should allow all the work
that's been done with the bogl drivers to be brought in to the nanoX project.

In addition, the text draw routine needs to subtract the font->height
from the y value before displaying, if we want X-like semantics.


Greg

> --------------- Linux- the choice of a GNU generation. --------------
> : Alex Holden (M1CJD)- Caver, Programmer, Land Rover nut, Radio Ham :
> -------------------- http://www.linuxhacker.org/ --------------------
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####
> 

:
> 
> 8bpp works fine.
> 16bpp silently fails (the initialise call fails).
> 24bpp fails with:
> bogl-cfb.c:54: memset_var: Assertion `(((unsigned int)dst * 8) % b) == 0' failed.
> 32bpp seems not to work at all on the NetWinder.
> 

	Are you using the fbset program to change between modes before
running nano-X?  Can you detail exactly how you change the system framebuffer
between these different modes?

Greg