Lee Brown wrote:
> On Sat, 04 Nov 2000, Stefan Seefeld wrote:
> > Lee Brown wrote:
> > > Why can't we just let the client (Stefan) draw to the offscreen part
> > > of the framebuffer?
> > had you followed the recent discussion, you would know. As always, GGI's aim is
> > to insulate h/w specifics from the client. Some graphics cards might have special
> > memory for this kind of things, z-buffer, etc.
> > What if my card doesn't have as much memory as I request ? What if I want multiple
> > offscreen buffers ?
>
> What if GGI just told you how much memory was available, gave you the ability
> to access it, and let you regulate it for yourself? Would that be an
> improvement?
>
> > In fact, I think video memory management should be at the very core of GGI,
>together
> > with drawing primitives. Every advanced program will require that.
>
> I agree that the concept of a visual needs to address the fact that it is
> possible to have non-viewable target regions and give the user the ability to
> make full use of this resource. IMHO, GGI should make things possible, not
> limit the possiblilties.
>
> Lee Brown Jr.
> [EMAIL PROTECTED]
It seems to me that in the end we're asking for something like DirectDraw (on Windows,
you know...) and its surfaces.
Although DirectDraw is quite messy (from the programmer and the user point of view,
COM architecture, etc... ) because it doesn't protect the video memory from malicious
programs, it's a working implementation on many graphics boards. So, maybe the GGI team
should take a look at it. By the way, has this team told with the DRI one?. I think the
DRI project is doing the things wrong. They are putting all this 3D management stuff in
the X Server (and in the kernel), but they don't manage 2D graphics well (nor does the
X Server, nor even the DGA architecture). Aren't they putting they noses in a terrain
that the awaited KGI direct video memory hardware management system (that should reside
in the kernel, at least in part,... ) should conquest?
