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