On Sat, Sep 24, 2011 at 5:24 AM, Christian Pühringer cip@gmx.at wrote:
a). Extract images from zim to local file system and provide them over a ContentProvider. b) Replace image src with base64 encoded image data. (Either directly on loading of article or by using java script)
I'd be inclined to try the base64 data URIs for simplicity: you won't have to deal with cleaning up and maintaining a cache of extracted files.
On the other hand, data URIs will probably take up more memory, and you have to spend a little extra time on base64 encoding/decoding. Try it and see! :)
While this is not a problem with C code even on embedded devices, it seems to be a problem with Java: Reading an article at the end of a cluster takes close to 20 s on my test android phone. As the phone is pretty low end (Orange Boston ) and uses an old android version (Eclair) without a just-in-timer compiler I expect that other models are significantly faster. However, I doubt that the performance gain will be sufficient to bring article load time in a range of << 1 s. I am going to try it out, but I'd expect that we probably have to switch to native code for zimlib support. (At least for liblzma).
Eek! Definitely should test on newer devices/OSs as well, at least to get a baseline to compare the native code against.
(Note that not all Android systems are necessarily ARM -- for best portability, being able to use the Java LZMA code if the native library can't be loaded might be nice.)
An other approach is to reduce cluster size of zim files. I am not sure right now whether this would be sufficiently fast, but it is worth considering it as an option: While for android being able to use the java implementation is a benefit, it is also not a big thing if native code has to be used. However, more concerning is that it may not be possible to support for Windows Mobile at all with the current cluster size. (Because AFAIK not native code is supported)
Windows Mobile / Windows Phone should have a decent JIT compiler for .NET code, so it's at least worth testing...
-- brion