Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!elroy.jpl.nasa.gov!ncar!gatech!udel!mmdf
From: PPH93%DMSWWU1A.BITNET@cunyvm.cuny.edu (Thomas Heller)
Newsgroups: comp.os.minix
Subject: Re: SCREEN proposal
Message-ID: <56092@nigel.ee.udel.edu>
Date: 12 Jun 91 09:35:58 GMT
Sender: usenet@ee.udel.edu
Lines: 87


Frans,

Thank you for moving this discussion over here.
After thinking over the whole stuff for some days, I have some suggestions.

Level 1 (Driver):

SCRMAP should NOT be supported on IBM PC's for two reasons:
  1. It's unportable, only possible on systems with a MMU (80386).
  2. It's expensive. Mapping to user space replaces the specified buffer by the
	video memory, the buffer itself is mapped out of existance.
  3. It does not improve performance.

  The only reason to have the screen mapped is to allow access from C-code
  to the screen, which is nice while implementing and debugging the graphics
  library, but not needed thereafter.

Level 2 (Low level library functions):
  The basic primitives needed are indeed bit-block-transfer (bitblt),
  drawing lines and pixels, and handling the color attributes. Circles and
  ellipses for example can be done with these functions.
  (This may not be an efficient approach for drawing filled unregularly
  shaped objects.)

 My suggestions are:

  - Graphical contexts are handled at a higher level. Functions to draw a line
    or pixel should take the color as a parameter.

  - The 'op' parameter in the bitblt function is encoded as a 4 bit binary
    code in the following way:
    The graphic library header file defines two symbolic constants like
    'SRC' and 'DST'. These are 4 bit constants like '0101b' and '0011b'.
    The 'op' parameter for the bitblt function can be specified as any boolean
    combination of these two constants.

    Examples:
	specifying 'op' as (SRC^DST) will exor the source bitmap to the
	destination bitmap.
	specifying 0 (zero) as 'op' will clear the pixels in the destination,
	0xF will set them.
	( If you wish, you can also specify these as (DST&~DST) and
	 (DST|~DST) resp.)
	SRC will simply copy the source bitmap to the destination.

    There are 16 possible combinations of these two constants, which should
    all be covered by the bitblt function (one of them, 'DST', is really
    a NOP).

    It would be nice if the functions which draw pixels and lines also
    take the 'op' parameter, although obviously only 4 of the combinations
    make sense here: DST (is the nop again), ~DST (invert), 0 (clear)
    and 0xF (set).

  - The graphical library has to handle 'bitmaps'.
    Bitmaps are portions of memory thought as rectangular windows of a certain
    size ('width' pixels wide, 'height' pixels high, 'depth' bits deep
    depending on the number of colors/bitplanes).

    The actual memory layout of a bitmap depends on the display hardware.
    It is up to the library to hide this.

    Bitmaps may be part of the video memory, they may also be in memory
    or eventually on the disk (in temporary or permanent files).

    The graphical library header file should define a BITMAP structure
    like:

    typedef {
      unsigned short width, height, depth;
      char *data;				/* pointer to bitmap data */
      int type; 		/* SCREEN, MEMORY, DISK, maybe some more  */
    } BITMAP;

  - The drawing primitives take as an additional parameter a pointer to
    the bitmap where the action has to be performed. Bitblt obviously
    has to take two bitmap pointers.

  - Functions has to be provided to create and destroy bitmaps.

Levels 3, 4 and 5:
  No suggestions here (from me), I think this is up to the application/server
  programmer. In fact even all of these levels can be combined in one program.

----------------------------------------------
Thomas Heller, University of Muenster, Germany   <PPH93@DMSWWU1A.BITNET>