On Sat, Sep 24, 2011 at 5:24 AM, Christian PĆ¼hringer <cip(a)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