nanogui: Thread: bogl routines

Ben,
	In order to keep nanogui simple, I'm thinking about having the mouse
pointer drawing/undrawing routine be the same driver routine as the low-level bit
blt (except that the pointer is a monochrome bitmap, and there's also a mask, which
means that the bitblt needs to do a mask AND and then image OR).

	In addition, I need to add a pixel read routine, which would be shared for the 
pointer save.

What do you think?

Greg

Greg Haerr ####@####.#### writes:

	   In order to keep nanogui simple, I'm thinking about having the mouse
   pointer drawing/undrawing routine be the same driver routine as the low-level bit
   blt (except that the pointer is a monochrome bitmap, and there's also a mask, which
   means that the bitblt needs to do a mask AND and then image OR).

	   In addition, I need to add a pixel read routine, which would be shared for the 
   pointer save.

   What do you think?

That sounds fine to me, except that I think a pixel read routine would
be too slow for use with a mouse pointer.  I think that you really
want a screen->buffer bitblt.

How about signatures something like this:

	/* Screen->buffer bitblt.  If BUF is a null pointer, returns
           the size of buffer necessary to save the given region;
           otherwise, copies region (X1,Y1)-(X2,Y2), excluding row
	   Y2 and column Y2, into BUF, in a format suitable for use
	   with bogl_brestore(). */
	size_t bogl_bsave (int x1, int y1, int x2, int y2, void *buf);

	/* Buffer->screen bitblt. */
	/* Should the region size be passed in as (X2,Y2) or stored
	   in BUF by bogl_bsave? */
	void bogl_brestore (int x1, int y1, void *buf);

	/* Screen->screen bitblt. */
	/* Would you prefer a 
           (X1,Y1)-(X2,Y2) => (X3,Y3)-(X3+X2-X1,Y3+Y2-X2) style? */
	void bogl_bmove (int sx, int sy, int dx, int dy, int w, int h);

How do you propose to handle masking?

> That sounds fine to me, except that I think a pixel read routine would
> be too slow for use with a mouse pointer.  I think that you really
> want a screen->buffer bitblt.

	I meant that, rather than reading it all pixel-by-pixel.

> 
> How about signatures something like this:
> 
> 	/* Screen->buffer bitblt.  If BUF is a null pointer, returns
>            the size of buffer necessary to save the given region;
>            otherwise, copies region (X1,Y1)-(X2,Y2), excluding row
> 	   Y2 and column Y2, into BUF, in a format suitable for use
> 	   with bogl_brestore(). */
> 	size_t bogl_bsave (int x1, int y1, int x2, int y2, void *buf);

	Instead of passing a NULL pointer, an entry point like

	BITMAP *bogl_createbitmap(x1, y1, x2, y2); 

	might be used.  An idea here would be that the mid-level graphics
routines don't know about the low-level format, and call the low-level drivers
to read/write/create all this stuff. 



> 
> 	/* Buffer->screen bitblt. */
> 	/* Should the region size be passed in as (X2,Y2) or stored
> 	   in BUF by bogl_bsave? */
> 	void bogl_brestore (int x1, int y1, void *buf);
> 
> 	/* Screen->screen bitblt. */
> 	/* Would you prefer a 
>            (X1,Y1)-(X2,Y2) => (X3,Y3)-(X3+X2-X1,Y3+Y2-X2) style? */
> 	void bogl_bmove (int sx, int sy, int dx, int dy, int w, int h);


	I like the src x,y dst x,y better than the x1, x2, x3.


	I need a little more thought on this, but an idea would be that
the BITMAP * structure might know whether the bitmap is a memory or screen
bitmap.  Then a single bitblt routine could be called, and the driver would ultimately
split out to the three low-level bitblts similar to your thoughts.


> 
> How do you propose to handle masking?

	First the bitblt routines need to run in SET, OR, AND, and XOR transfer
modes.

	Then, we need bitmap monocrome->color and color->monocrome conversion
routines.

	So, a monocrome or color cursor could be implemented near like you started
with an image and mask bitmap.  The mask bitmap is converted to a color bitmap
if the device screen is color.  Then the screen is bitblt AND'd with the mask.  Then
the image is OR'd with the screen with a bitblt.

	This may sound complicated, but if we're ever going to display images,
which I think is required even in a nano-system, we need all the bitblt stuff.  BTW,
the color of a monocrome cursor could also be controlled, rather than having it
hard-coded in a specialized cursor draw routine.  Of course, for raw speed, we
could always leave the cursor draw stuff in...


Greg


> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####
> 
>