From: Brian Julin <bri@forcade.calyx.net>
  To  : ggi-develop@eskimo.com
  Date: Wed, 10 Mar 1999 09:30:12 -0500 (EST)

Re: Sprites in video memory

On Wed, 10 Mar 1999, Marcus Sundberg wrote:
> you have the option of creating any kind of lightweight visuals
> in an extension. By simply truncating the visual struct and defining
> what operations are permitted on it you can use the functions in
> gc.c and stubs.c to draw onto any small visual which may consist
> of for example only these entries:
> 
> 	unsigned int      version;
> 	void	         *targetpriv;	/* Target private data */
> 	ggi_gc		 *gc;		/* Graphics context */
> 
> 	struct ggi_visual_opdraw    *opdraw;	/* Drawing operations */
> 
> Sounds like a good idea?

Yes, but I'd move the the gc under the opdraw so it's optional.

You'd have to typecast those truncated visuals somehow, but
that could work.  An alternate idea -- what if we were to seed the 
visual->version member with a magic number, play some header/endian 
tricks so that it is a union of the magic number (int8) and the 
version (the rest of the int) and give it a different magic number 
for "batch visuals" with code like this in stubs.c that implements 
both a sanity check and a multiplexing operation:

int ggiPutPixel(ggi_visual *vis,int x,int y,ggi_pixel col)
{ switch (vis->version.magic) {
	case GGI_MAGIC_VISUAL: return vis->opdraw->putpixel(vis,x,y,col);
	case GGI_MAGIC_BATCH_VISUAL: 
	  return vis->(ggi_batch_visual *)targetpriv->opdraw\
->putpixel(vis->privdata, vis, x, y, col);
	default: INTERNAL_ERROR;
	};
}

For a regular visual everything proceeds as normal (you just lose a cycle
to the switch statement).  For a batch visual, the parent visual has 
different function prototypes in the opdraw, opgc, etc to take two pointers, 
one to the parent visual which is stored in targetpriv in the child, and 
one to the instance visual itself so the instance's data is available to 
the parent.

A batch visual would then be reduced to:

typedef struct ggi_visual {
	int version;
	void *targetpriv; /* pointer to parent visual */
	/* private instance data (or pointer to) here, e.g.
           int sizex, sizey;
	   mem_vaddr loc;
	   int posx, posy; 
        */
}

In either case you can't just blindly copy one visual to another,
as they can vary in size, but that will probably be easy to work around.
The advantage to your approach is no alteration of stubs.c and no
extra CPU cycles.  The disadvantage is a more limited choice as to what
you do and do not want in the reduced instance visual, and lack
of inheritance of a full visual structure, and excess baggage for
each op set you add.

We should build it your way first, since it's less disruptive,
and then maybe consider the parent/child visual model.

--
P.C.M.C.I.A. stands for "Plastic Connectors May Crack If Adjusted"
                                                             -- me
--
Brian S. Julin