Lee Brown wrote:
>
> >what is the support for offscreen video memory allocation ?
> >I'm not sure I use the correct terminology, so here is what
> >I have in mind:
>
> Why can't we just let the client (Stefan) draw to the offscreen part
> of the framebuffer? I wrote a little demo (with minor changes to the fbdev
> code) program that allowed me to draw offscreen (outside of the virtual area)
> and then use ggiCopyBox to blit it to the viewable (virtual/pannable) area when
> needed. What am I missing here?
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 ? The offscreen manager would know how to deal with that (much
as the kernel's memory manager: with paging and swapping). It's just wrong to let
the client mess with that.
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.
Regards, Stefan
_______________________________________________________
Stefan Seefeld
Departement de Physique
Universite de Montreal
email: [EMAIL PROTECTED]
_______________________________________________________
...ich hab' noch einen Koffer in Berlin...
