Better image cache
Brought to you by:
herrekberg
Menu
▾
▴
#72 Better image cache
While I was deciding on a comic reader, I tried several alternatives to Comix.
One (a wxWidgets-based C++ reader named Comical) was greatly inferior to Comix, but it did have one big benefit. It's cache was far superior.
First, I suspect that Comix 3.6.3 might have a broken caching mechanism since it takes about a second and a half to switch pages no matter which page I'm jumping to. As such, I'll give Comix the benefit of the doubt and assume that, under normal circumstances, switching to the next page is instantaneous as with all the other tools I tried.
The feature I'm requesting is the ability to cache a user-selectable number of pages both before AND after the current one. (Comical defaults to 10. 5 before and 5 after as far as I can tell)
As I mentioned in my previous bug report, I am a Python programmer, so if I can ever find some time, you may find a patch attached to this.
Thanks for the great tool
Logged In: YES
user_id=1250348
Originator: NO
I'm a bit surprised that switching pages takes such a long time for you. On my computer (a few years old) it is seemingly instantaneous flipping forward unless the image viewed is very large. Flipping backwards might seem a bit slower, and ad hoc flipping is slowest. Still, using reasonably sized images it should not take a second and a half. The times I have used Comical, I haven't noticed it as much faster, although I admit I haven't made any structured comparisons.
What scaling method are you using (Preferences -> Scaling)? I recommend using "Tiles". I will remove the two options, "Bilinear" and "Hyper", in future versions because they are slower and I can't honestly see any difference between them and "Tiles". As it is now, people might be tricked into using a slower method that presents no better results, having just "faster/bad quality" and "slower/good quality" will be preferable. So anyway, if you are using "Bilinear" or "Hyper" I recommend switching to "Tiles". It should not have such a severe effect as a one and a half second delay though.
I have thought about using multiple caches just as you describe. However, when I wrote the code I made some (limited) tests that showed that the load time of reading a JPEG image from disk is mush less than the time it takes to parse the JPEG data into raw image data. Thus I decided to store the cache in memory as raw image data and not as JPEG data. The problem with this is of course that raw image data takes up a lot of memory space, so I decided to limit it to the next image. I can't really remember what tests I did, and it's not impossible that they were flawed somehow. I will take a closer look into this again when I get time for it, there are lots of things that need re-doing...
Logged In: YES
user_id=302370
Originator: YES
Actually, I am using Tiles. For the record, I'm using a Celeron 2.0Ghz with 1GiB of RAM and the hard drives are pretty much idle except for Comix.
Comix 4 seems to fix this performance issue.