Opportunity for speedup

Mitch Bradley wmb at laptop.org
Thu Feb 19 16:23:53 EST 2009


david at lang.hm wrote:
>
> right, but why read the current framebuffer? you don't touch most of 
> it, you aren't going to do anything different based on what's there 
> (you are just going to overlay your new info there) so all you really 
> need to do is to write the parts tha need to change.

You don't read the on-screen part of the framebuffer.  You copy delta 
data from off-screen framebuffer memory to portions of the on-screen 
framebuffer memory.

On-screen vs. off-screen is irrelevant to the speed - read access to the 
memory that is reserved for display controller use is similarly "slow" 
in both cases.  But considering that the delta data is small compared to 
the full images, it's worth it to store the deltas there, thus avoiding 
the overhead of the other alternatives for maintaining the context from 
one call to the next.

Those alternatives are:

a) Server process maintains context on behalf of repeatedly-executed 
client process.  This incurs the complexity of client-server 
architectures - setup/teardown, library overhead, interprocess 
communication, scheduling.

b) Client program reads new delta data from a file on each invocation.  
This incurs the filesystem overhead of opening a file on each invocation 
(in comparison, the off-screen framebuffer solution requires only a 
single open() and a single read() on the first invocation.

c) Client program reads delta set into a shared memory segment and then 
reattaches to that segment on subsequent invocations.  This is similar 
to the framebuffer approach except that it uses faster memory for the 
persistent storage.  It might be a win from a speed perspective, but it 
is a bit more complex, requiring the program to deal with two memory 
objects instead of just one.  The total amount of time that it could 
possibly save is about 50 mS, since that it the time it takes to read 
the delta set from the off-screen framebuffer.  And if we use the RLE 
encoding suggested by Wade, the amount of off-screen data is halved, so 
the best-case savings are reduced to 25 mS total.





More information about the Devel mailing list