New commits:
http://git.directfb.org/?p=core/DirectFB.git;a=commit;h=6cffc100034190a068b4fa2efb67ab96e01fbdfd
commit 6cffc100034190a068b4fa2efb67ab96e01fbdfd
Author: Denis Oliver Kropp <[EMAIL PROTECTED]>
Date: Sun Dec 9 22:17:18 2007 +0100
SURFACE-CORE: Added CSALF_VOLATILE and CSALF_PREALLOCATED. Reimplemented
"thrifty-surface-buffers".
The "thrifty-surface-buffers" option is implemented by iterating through
all allocations at the end of
an update_allocation() and deallocate all other allocations, unless they
have the CSALF_PREALLOCATED
flag. In the latter case it would not be a benefit, but the disadvantage of
losing an allocation that
is still up to date and would probably be faster (CPU read) than others.
=> The 'preallocated' surface pool sets CSALF_PREALLOCATED upon allocation.
Another flag CSALF_VOLATILE has been introduced. In case of a write access
to one allocation, any other
allocation is deallocated if it has the flag. This is independent of the
"thrifty-surface-buffers" option.
=> The 'local', 'shared' and 'preallocated' surface pools set
CSALF_VOLATILE upon allocation.
That means the preallocated surface buffers are kept as long as they're
still up to date with other
allocations (copies of them), e.g. an image resource loaded into
accelerator memory, never written to,
but read from by GPU as well as CPU. As soon as one of the allocations has
been written to, the
preallocated buffer becomes useless, if we cannot write back to it (which
we don't as there's not yet
a way to specify read/write permissions when creating preallocated
surfaces).
src/core/local_surface_pool.c | 3 ++-
src/core/prealloc_surface_pool.c | 5 +++--
src/core/shared_surface_pool.c | 3 ++-
src/core/surface_buffer.c | 31 +++++++++++++++++++++++++++++--
src/core/surface_buffer.h | 8 +++++---
5 files changed, 41 insertions(+), 9 deletions(-)
_______________________________________________
directfb-cvs mailing list
[email protected]
http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-cvs
