Re: memory efficient compisiting

Jon Smirl wrote:
> I'm still working on the Radeon standalone OpenGL implementation that is merged
> with framebuffer. But while I'm doing that I was thinking about buffer
> management and compositing. 
> 
> Building a screen with transparent windows requires that the contents all of the
> windows be available. But large windows on a 1280x1024x32 screen can take 5MB of
> memory each. That's a lot of VRAM to waste for command line.

Ideally, xterms and other windows that don't really need much color 
depth would be stored at 8bpp (or less) and expanded to full RGBA 
during rendering.  Relatively static images like background wallpapers 
might even be stored as compressed textures.

Are simultaneous, heterogeneous pixel depths supported now in the new 
X server code?


> Refetching a
> window's contents over a network will also take a lot of time. If one of the
> transparent windows contains video the composition process is continuous. 
> 
> Two solutions occurred to me: 1) keep non-performance sensitive windows in AGP
> space, but I'm not sure the Radeon can address huge (256MB) amounts of AGP
> memory. 2) Store the windows' contents as a high level display list. 
> 
> Can the Cairo scheme support high level caching of content for replay at
> composition time? You could then allocate a full sized screen buffer for each
> texture unit and treat these as caches. If you need a window that wasn't in the
> cache you would replay the Cairo cache into the buffer.
> 
> One problem is operations that rely on the previous contents of the window
> buffer such as scroll window. This would have to be handled by playing the Cairo
> commands for the previous state into a clip region and then merge those results
> into the new command cache. If instead you tried caching the previous window
> state as a bitmap, the cache would be just as big as a dedicated buffer and
> nothing would be gained. Another alternative would be upon encountering a scroll
> window type operation, simply send the windows a full window draw command.
> 
> What's the xserver solution to this problem?
> 

Good questions.

-Brian