Opportunity for speedup

[david at lang.hm]

On Thu, 19 Feb 2009, Bobby Powers wrote:

> On Thu, Feb 19, 2009 at 1:22 PM, C. Scott Ananian <cscott at laptop.org> wrote:
>> I'd suggest just uncompressing the various image files and re-timing
>> as a start.  The initial implementation was uncompressed, but people
>> complained about space usage on the emulator images (which are
>> uncompressed).  The current code supports both uncompressed and
>> compressed image formats.  For uncompressed images, putting the bits
>> on the screen is an mmap and memcpy, so I can't imagine any
>> implementation being faster than that (it's possible, of course, that
>> what's stealing CPU is the shell's invocation of the client program;
>> recoding just that little part in C should be trivial, since it does
>> nothing but write to a socket IIRC.)
>>
>> Anyway, further benchmarking of the current implementation is probably
>> worthwhile before a complete reimplementation is called for.  But if
>> you want to reimplement it from scratch, go nuts.
>>  --scott
>
> I already re-implemented it - it was a fun optimization project and
> introduction to lower level systems programming.  Using Mitch's D565
> format to keep track of only the parts of the image that change cut
> down the implementation size significantly.  Its now only 2
> uncompressed images (frame00.565 and ul-warning.565), and <300KB of
> differences for the animation sequence.  I understand reads from video
> memory (which I think is what the framebuffer is?) can be extremely
> slow, so it could turn out faster to open a D565 file, mmap it and
> mcpy the several tens of kilobytes of differences to the framebuffer
> than it is to read those differences from one part of video memory to
> another.
>
> This is where benchmarking should give some clearer answers.

if you have the diff of the images, do you need to read from the 
framebuffer at all? since you know what you put there, and know what you 
want to change, can't you just write your changed information to the right 
place?

David Lang