Subject:
RE: bogl routines
From:
Greg Haerr ####@####.####
Date:
14 May 1999 19:12:18 -0000
Message-Id: <01BE9E0B.21B68070.greg@censoft.com>
> 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: ####@####.####
>
>