memory efficient compisiting

Jon Smirl <jonsmirl-/[email protected]>
Newsgroups gmane.comp.freedesktop.xserver
Message-ID <[email protected]>
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. 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?

=====
Jon Smirl
jonsmirl-/[email protected]

__________________________________
Do you Yahoo!?
Yahoo! Search - Find what you’re looking for faster
http://search.yahoo.com
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.