On Sat, Sep 24, 2011 at 5:24 AM, Christian Pühringer <[email protected]> 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
_______________________________________________ dev-l mailing list [email protected] https://intern.openzim.org/mailman/listinfo/dev-l
