Quote:
Originally Posted by hawhill
Did you test LZO compression? Might be easier on the CPU, plus your program could implement it itself and decompress directly to the framebuffer, saving a copy. Compression ratio will probably be worse, though.
|
I have some really fast LZW compression in other code on my kindle. For now I am relying on gzip and gunzip in the execution pipeline to handle compression for me. I tried zip/unzip but the files were actually a bit smaller with gzip/gunzip, and you do not need the extra "-p" parameter unzip needs.
My goal is always to get maximum performance from minimum lines of code, which is part of why I (and others) dislike whitespace so much.
I have been doing this since the days when business computers only had 4KB (yes kilobytes) of memory. One of the first hard drives I worked with was the size of a commercial laundry washing machine and could store an entire 512KB (half megabyte) on those big heavy disk packs.
The mind-boggling waste in modern code (just because you CAN) really astounds me. I lean the other direction.
Anyway, I had to go through a lot of iterations of stepwise-refinement to get this level of consistent performance from small code that works on all eink kindles, and I know of several ways to make major improvements in speed and performance (later). I work in baby-steps of small improvements that build upon each other.
The point is -- I like to push things was beyond what most people think is even possible. The eink Doom video on youtube (running on a different eink device) was only about 4 FPS, and I am doing nearly twice that even on a K3 (and I have seen my K5 go up to almost 40 FPS with carefully designed video content). Because eink persistence allows lower framerates, which allow more video compression (frame dropping), I have standardized on K3-speeds even for the newer kindles. The K4main "hybrid" video driver (K5 hardware using K3 driver by HAL translation) drops far more frames than the K3. K4diags has MUCH better animation support.
Anyway, to some my code may appear incomprehensible "write-only" code, but for my purposes being able to see more code without scrolling allows ME to comprehend more of it at the same time. Scrolling limits my thought processes while absorbing code. And people can always run my C code through AStyle to read it anyway...
