From: Kenneth Johansson <ken@canit.se>
  To  : ggi-develop@eskimo.com
  Date: Sun, 28 Mar 1999 00:17:58 +0100

Re: Some more "texturetalk"

Brian Julin wrote:

>
> Here's how it works.  You attach the libGGIAuxBuf extension,
> either before (preferably) or after setting a mode on the
> normal visual.  This gives you a new operation ggiAuxBufAlloc
> on the visual which you can use to define an off-virtual-screen
> buffer (Z,Sprite,Texture, what have you.)  This takes away the
> poor practice of forcing the virtx, virty to do double duty
> as an auxiliary buffer allocation -- so don't ask for virtual
> screen resolution unless you really want just that.  It also
> loads the "auxbufserver" renderer on top of the existing one
> (or if that's not possible, the auxbufserver renderer must be
> preloaded by a nested construct like display-tile does), or if
> none is chosen yet, it will do so during the setmode call.
>

Nice.


>
> If you have not set a mode, any call to ggiAuxBufAlloc merely
> prepares the visual's informational structures to anticipate
> needing these sprites.  You can then use advanced set/checkmode
> functions provided in the extension to ask the target to allocate
> these sprite areas when it sets the mode.  It will allocate the
> sprites in the order they were requested, and continue after
> failure to try to fit as many into video memory as it can.  The
> rest are shunted to main memory buffers.  There will be functions
> to check whether a particular buffer is in video memory or main
> memory, or force moves to/from video memory, or to lock a buffer
> into main/video memory so it never gets bumped out.  If the mode
> was already set using the standard ggiSetMode function, the
> allocation happens in realtime and you can check the results
> of each one as you do it, but this may result in fewer buffers being
> available since the setmode didn't know what you were going to want.
>

May I suggest that you separate the memory management and sprite into two
different things. Some types of data on the cards memory is not dependant on the
mode that it is operating. So you would first make a memory manger that just
allocate raw memory. This allocator have to be able to ask the allocated memory
to move if it can otherwise we will have to much fragmentation.

Why do I think that this is needed. Well I have read about matrox G400 chip and
they claim Support for unlimited number of simultaneous video windows and
sprites. They have not yet released the chip programing information so I dont
know how the sprites works but if they  have simply made the overlay also take a
mask (iregular overlay windows)I guess that we now have the possibility to
display 16 or 24 bit sprites on a 8 bit display and other cool things. This mean
that no copy of data is necessary but we will need a overlay structure of some
sort to controll it and that need to be in video mem to.

Then we have textures that have a multitude of different formats and also need
to be in onboard memeory.