This brings up another interesting point:
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:
There is often a need to double buffer content in some form,
and map (blit) it into the screen at specific times. Of course,
the way to do that with GGI is to allocate a set of (memory)
visuals and work with these.
So, what memory are the visuals allocated from ? Assuming that
they are allocated from video memory (framebuffer ?), I'd suggest
to think about a QoS (Quality of Service) issue: Given that video
memory is limited, some visuals would need to be allocated on regular
heap.
I might know when allocating visuals (drawing buffers) that some are
updated more frequently than others, i.e. they would profit much more
from being close to the graphic card. Is there (or could there be) any way
to expose some policy issues like these through an API for drawable memory
management ?
You will notice that this is an issue which I brought up a couple of
months ago already: I'm thinking of a 'Backing Store' for berlin, i.e.
for example for video intensive graphics, I'd like to make backups of
the scene graph in front and behind the graphic with the high frame rate,
such that I then don't need to traverse the scene graph on each redraw,
but rather map the three layers (back, animated graphic, front) into the
screen to keep it consistent with the scene graph (for example if the
exposed region of the animation isn't regular (rectangular), or if the
layers are translucent, such that I need to blend them together, rather
than just blitting them in.
Regards, Stefan
_______________________________________________________
Stefan Seefeld
Departement de Physique
Universite de Montreal
email: [EMAIL PROTECTED]
_______________________________________________________
...ich hab' noch einen Koffer in Berlin...
