> 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.
Umm - good point ... Marcus: We should talk about the region management once
again ... and finally implement it. I have stubs for blit functions from my
Libbse experimental thingy ...
> 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.
Yes. This is more or less what said extension will then do internally.
> > So, what memory are the visuals allocated from ? Assuming that
> > they are allocated from video memory (framebuffer ?),
> Your assumption is wrong, from targets.txt:
Not totally ... though in a nonobvious way, but I think I should mention
it:
> 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.
If you use mmap together with the option "an area specified by the
application", you can place a memvisual into vidmem.
> 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
Hmm - got to read that ...
CU, Andy
--
= Andreas Beck | Email : <[EMAIL PROTECTED]> =
