Opportunity for speedup

[david at lang.hm]

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 
> 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.

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.

David Lang