Oh, and you can feed one of the 565 files through my 'rle.c' program to see the compression ratio firsthand.<br><br><div class="gmail_quote">On Thu, Feb 19, 2009 at 1:56 PM, Wade Brainerd <span dir="ltr"><<a href="mailto:wadetb@gmail.com">wadetb@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">RLE (run length encoding) compresses sequences of identical pixels ("runs") as value/count pairs.<div><br></div>
<div>So abbbbbbbbbbccc would be stored as 1a 10b 3c.</div><div><br></div><div>The decompressor looks like:</div>
<div><br></div><div>while (cur < end)</div><div>{</div><div>   unsigned short count = *cur++;</div><div>   unsigned short value = *cur++;</div><div>   while (count--)</div><div>      *dest++ = value;</div><div>}</div>
<div>
<br></div><div>This can be faster than memcpy because you are reading significantly less memory than you would with memcpy, thus fewer cache misses are incurred.</div><div><br></div><div>Because the startup images are mostly spans solid colors, this kind of compression works very well.  If that were not the case, say if there were a left-to-right gradient in the background, RLE would probably make things worse, thus you have to be careful when choosing it.</div>

<div><br></div><div>But the smaller size on disk and in memory would probably improve performance in other ways as well.</div><div><br></div><div>Best,</div><div>Wade</div><div><div></div><div class="Wj3C7c"><div><br></div>
<div><br><div class="gmail_quote">
On Thu, Feb 19, 2009 at 1:49 PM, Bobby Powers <span dir="ltr"><<a href="mailto:bobbypowers@gmail.com" target="_blank">bobbypowers@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

2009/2/19 Wade Brainerd <<a href="mailto:wadetb@gmail.com" target="_blank">wadetb@gmail.com</a>>:<br>
<div>> On Thu, Feb 19, 2009 at 1:22 PM, C. Scott Ananian <<a href="mailto:cscott@laptop.org" target="_blank">cscott@laptop.org</a>> wrote:<br>
>><br>
>> I'd suggest just uncompressing the various image files and re-timing<br>
>> as a start.  The initial implementation was uncompressed, but people<br>
>> complained about space usage on the emulator images (which are<br>
>> uncompressed).  The current code supports both uncompressed and<br>
>> compressed image formats.  For uncompressed images, putting the bits<br>
>> on the screen is an mmap and memcpy, so I can't imagine any<br>
>> implementation being faster than that (it's possible, of course, that<br>
>> what's stealing CPU is the shell's invocation of the client program;<br>
>> recoding just that little part in C should be trivial, since it does<br>
>> nothing but write to a socket IIRC.)<br>
><br>
> I implemented a RLE compressor specifically for these 16bit image files the<br>
> last time this question came up.  This can certainly be faster than memcpy<br>
> since we are talking memory performance.<br>
<br>
</div>Can you explain this?  I don't think I have enough knowledge to<br>
evaluate your claim.<br>
<font color="#888888"><br>
bobby<br>
</font></blockquote></div><br></div>
</div></div></blockquote></div><br>