View Single Post
Old 02-10-2012, 12:24 PM   #57
rkomar
Wizard
rkomar ought to be getting tired of karma fortunes by now.rkomar ought to be getting tired of karma fortunes by now.rkomar ought to be getting tired of karma fortunes by now.rkomar ought to be getting tired of karma fortunes by now.rkomar ought to be getting tired of karma fortunes by now.rkomar ought to be getting tired of karma fortunes by now.rkomar ought to be getting tired of karma fortunes by now.rkomar ought to be getting tired of karma fortunes by now.rkomar ought to be getting tired of karma fortunes by now.rkomar ought to be getting tired of karma fortunes by now.rkomar ought to be getting tired of karma fortunes by now.
 
Posts: 2,986
Karma: 18343081
Join Date: Oct 2010
Location: Sudbury, ON, Canada
Device: PRS-505, PB 902, PRS-T1, PB 623, PB 840, PB 633
Quote:
Originally Posted by vomov View Post
Just found this app, and it works very good, but I have two questions:

What does the 'fine update' option actually do? I see it making something of a second 'flash' that does indeed improve the picture, but how does it work?

Why is it getting slower (20sec for a page flip) near the end of a large (200 pages, 35mb) CBR? I assumed it unpacked the whole thing in a temporary folder (as hinted by the menu option in the configuration), but is it actually unpacking only one image file, and thus losing time unpacking/skipping the previous files?
I'm not sure what the 'fine update' is for, and I wasn't even sure that it improved the picture when I looked at it. It was in the original code, and I thought that it might be important for the older models of ereaders, so I left it in with an option to enable/disable it. The code does a FullUpdate() followed immediately by a FineUpdate() (causing the second flash). There's no documentation for the Inkview SDK, so I have no idea what FineUpdate actually does.

Your guess about the slowdown is correct, that's exactly how it's done. The program used to unpack the whole archive at the beginning, but that took a long time for big archives, sometimes filled up the disk space and caused errors that way, and had problems with some file names if unpacked to one of the FAT filesystems. So, I changed it to unpack one at a time to fix those problems (and to remove the need for the external unrar and unzip programs). Still, 20 seconds is too long just for the skipping. I've noticed longer times if a compressed image file is very large (~10MB), but even that was only a few seconds. Also, the program unpacks the next image right after displaying the current one, so if you're reading for a few seconds per page, pressing Next gives you the next image pretty quickly. I haven't noticed such long slowdowns for CBR files with ordinary images myself. Maybe something else is going on.

The new "one image at a time" behaviour is for CBR and CBZ files. TAR archives are still handled the old way and unpacked en masse at the beginning, so that menu option only applies to those, now.

I have the source code available at my website, and gave the URL in post #5 in this thread. I should probably copy it to the first post to make it easier to discover.
rkomar is offline   Reply With Quote