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