Opportunity for speedup
david at lang.hm
david at lang.hm
Thu Feb 19 16:31:46 EST 2009
On Thu, 19 Feb 2009, Mitch Bradley wrote:
> 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
> 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
d) compile the delta set into the client program.
does this really need to be a general-purpose solution here? or is this
really only used for this specific purpose.
More information about the Devel