DirectFB - Home of the pragmatist Roadmap

[directfb-dev] Re: blanking of non-refreshing windows
Mailing List archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[directfb-dev] Re: blanking of non-refreshing windows

Quoting Torgeir Veimo:
> On Tue, 2003-09-09 at 17:07, Denis Oliver Kropp wrote:
> > Quoting Michel Dänzer (
> > > On Thu, 2003-08-21 at 23:12, Andy Isaacson wrote:
> > > > In general I want the system to work correctly an in a performant 
> > > > manner even if the number of windows exceeds available off-screen 
> > > > framebuffer memory.
> > > 
> > > It would be interesting how it performs in that case indeed; I don't
> > > expect it to be too bad though as it was quite usable even without any
> > > hardware acceleration.
> > 
> > The surface manager of DirectFB kicks out older window surfaces if
> > no free space is available. Only if many windows overlap while
> > being transparent, it could slow down noticably, because all windows
> > are needed to recompose the stack. But with a 32MB card I have space
> > for many windows ;)
> Can you DMA them to main memory using run length compression?

They could be blitted to AGP memory, once DirectFB supports different
memory pools. An abstract management of memory which can be read/written
by CPU and/or GPU with support for dynamic physical allocation is a very
interesting and important TODO. This should include all kinds of UMAs,
GARTs etc.

I don't think that RLE is supported, neither on storage, nor on transfer.

Ville did an experimental AGP patch which added DSCAPS_AGPONLY.
It could be used for all window surfaces. The card memory would stay free
for fonts, icons, images, sprites or video only surfaces (e.g. layers).

Best regards,
  Denis Oliver Kropp

| DirectFB - Hardware accelerated graphics |
|                 |

                            Convergence GmbH

Info:  To unsubscribe send a mail to with 
"unsubscribe directfb-dev" as subject.

Home | Main Index | Thread Index / Development / Old Archives