Stefan Seefeld <[EMAIL PROTECTED]> writes:
> 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.
It is *NOT* the way, and will never be!
The correct way is to use the not-yet-written blitting extension,
so you can get hw accelerated blits when supported.
Until that has been written you should first try to set a mode
with a virtual Y-resolution higher than the physical and use the
offscreen area for caching images, and ggiCopyBox() for blitting.
Only if that fails you should resort to using a memory visual and
crossblit.
> So, what memory are the visuals allocated from ? Assuming that
> they are allocated from video memory (framebuffer ?),
Your assumption is wrong, from targets.txt:
memory-target
=============
Description
+++++++++++
Emulates a linear framebuffer in main memory. This memory area can be
a shared memory segemnt, an area specified by the application, or be
malloc()ed by the memory-target itself.
> 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 ?
The idea is to implement simple offscreen memory requesting in
LibGGI, and to let the blitting extension have all the intelligence.
The blitting extension will have some sort of priority based API
for allocating areas of either offscreen video memory or RAM, and
also moving areas between these two types of memory. Something in the
line of http://www.xfree86.org/4.0.1/DESIGN12.html
> 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.
//Marcus
--
-------------------------------+------------------------------------
Marcus Sundberg | http://www.stacken.kth.se/~mackan
Royal Institute of Technology | Phone: +46 707 452062
Stockholm, Sweden | E-Mail: [EMAIL PROTECTED]
