There have been a couple of these this month, and keeping stuff that should only ever run once piling up in their respective module was getting ugly, especially when it's usually simple stuff (settings, files).
So, move everything to a dedicated module, run by reader.lua on startup, and that will actually only do things once, when necessary.
* CalibreMetadata: Get rid of the now useless NULL-hunt: here, this was basically looking for `rapidjson.null` to replace them with... `rapidjson.null` :?. IIRC, that's a remnant of a quirk of the previous JSON parser (possibly even the previous, *previous* JSON parser ^^).
* CalibreSearch: Update the actually relevant NULL-hunt to make it explicit: replace JSON NULLs with Lua nils, instead of relying on an implementation detail of Lua-RapidJSON, because that detail just changed data type ;).
* UIManager: Make sure tasks scheduled during the final ZMQ callback are honored. e.g., the Calibre "Disconnect" handler. This happened to mostly work purely by chance before the event loop rework.
* Calibre: Restore a proper receiveCallback handler after receiving a book, in order not to break the "Disconnect" handler's state (and, well, get a working Disconnect handler, period ^^).
* Calibre: Unbreak metadata cache when it's initialized by a search (regression since #7159).
* Calibre: Handle UTC <-> local time conversions when checking the cache's timestamp against the Calibre metadata timestamp.
* Bump base (Unbreak CRe on Android, update RapidJSON)
Cache's state tracking
Re #7510
Legacy cache has to be deleted in Cache,
*before* the first getDiskCache call.
Reword the "Clear caches" Dev menu entry & callback:
We now have an actual "Restart" action (on most, if not all, platforms).
And we clear the whole cache folder, which may host other things (e.g.,
fontlist)
* Modernize jit syntax
It's built-in, no need for a require anymore.
* Flag Android should_restrict_JIT again
It's mildly helpful at putting off the inevitable.
(very, very, very, very mildly).
* Bump android-luajit-launcher
https://github.com/koreader/android-luajit-launcher/pull/281
If the most recently used global cache item refers to the same
page, it would be overwritten. This will happen when closing a
paged (PDF/DjVu) document on the same page you opened it, as well
as when opening and closing EPUBs with crengine because it uses
its own cache.
Fixes#3846.
to make koreader on Android more stable
and with these opt params:
```
require("jit.opt").start("sizemcode=64","maxmcode=64", "hotloop=10000")
```
The strategy here is that we only use precious mcode memory (jitting)
on deep loops like the several blitting methods in blitbuffer.lua and
the pixel-copying methods in mupdf.lua. So that a small amount of mcode
memory (64KB) allocated when koreader is launched in the android.lua
is enough for the program and it won't need to jit other parts of lua
code and thus won't allocate mcode memory any more which by our
observation will be harder and harder as we run koreader.
Currently only tested on Ubuntu-touch emulator with framework
ubuntu-sdk-14.10 for armhf.
The ubuntu-touch port is binary compatible with the Kobo port
major changes in this PR are:
1. rename the emulator device to sdl device since both the emulator
and the ubuntu-touch target use libsdl to handle input/output.
2. ubuntu-touch app has no write access to the installation dir so
all write-outs should be in a seperate dir definded in `datastorage`.
the cache would behave badly when the same item was insert()ed twice:
it would add the size twice to memory consumption, but would never substract
it twice when purging the (actually single) object from cache. So the cache
would seem to fill up while in fact it wasn't.
In reflowing scroll mode with 2 pages hinting, 4 full page blitbuffers
and koptcontexts should stay well in cache in the most demanding cases,
with two pages shown on screen and two pages rendered in background.
Since blitbuffer size is halved the size of page, we need cache size
to be 6 times an average reflowed page size.
For Kobo Aura HD which has a resolution of 1440×1080, a reflowed page
could become 1080×4800. So 30MB of cache is demanded for this case.
This PR implements dynamic cache size allocating according to size of
system free memory. By default it will use 20 percent of free RAM with
a clip specified by DGLOBAL_CACHE_SIZE_MINIMUM and
DGLOBAL_CACHE_SIZE_MAXIMUM which are 10MB and 30MB respectively by default.
