From: Jon M. Taylor <taylorj@ecs.csus.edu>
  To  : ggi-develop@eskimo.com
  Date: Thu, 20 Aug 1998 20:05:21 -0700 (PDT)

Re: DirectBuffer extension requests?!(!) (was Re: LibGGI3D RFC)

On Thu, 20 Aug 1998, teunis wrote:

> On Thu, 20 Aug 1998, Marcus Sundberg wrote:
> 
> > > Supposedly DirectBuffer handles this.  Will someone -please- tell me the
> > > status on non-primary-display DirectBuffers?!?!?!?!??!
> > > WHAT NEEDS DOING?
> > 
> > Well, someone needs to write an extension that provides functions
> > to request such buffers, and then someone needs to add functions
> > for this into the KGI API, that's all. ;-)
> 
> Okay - please!
> Any ideas?

	First, let's define our terminology.  A DirectBuffer is a memory
buffer which is specified to be located on a particular type of storage
(video RAM right now) and/or has a hardware-specific internal
layout/structure, and/or needs specialized handling methods.  Am I in the
ballpark?

> This'll be handy for lotsa stuff (movie players, anything with BITBLT (X
> comes to mind), 3D textures, videocards with subwindow support, font
> loading/unloading [on S3/textmode this is present in text memory, on
> videomodes it'd be handy for fast blitting :])

	Any place where "memory" is not just a bunch of bits.  This goes
beyond video hardware - the SoundFont storage in a Soundblaster AWE64
could be set up as a DirectBuffer.  So could any type of cache memory.  So
could disk storage, for that matter!  DB is a way to bypass virtual memory
systems and say "I specifically want *this* memory".

> I really don't know.  I've been fighting with one -weird- system for the
> last six months and have kind of forgotten how to write GGI extensions/etc
> (though I'm still mucking with drivers :)

	If you ever want to donate any code, working or not, to the
LibGGI3D cause I would be grateful.  You seem to know this stuff better 
than I do....

Jon

---
'Cloning and the reprogramming of DNA is the first serious step in 
becoming one with God.'
	- Scientist G. Richard Seed