mupdf is well known to have problems with rasterizing huge bitmaps.
In Kindle DXG example, huge means larger than memory size which is
128Mb. Generally, getting memory usage above 100M gets kindle blocked
so setting it to 64M seems like sane default. 96M might be upper
resonable limit.
K3 users with 256M or RAM might increase this value to 192M, but more
testing is needed.
For comparison, some full-page ads from Digital Linux Journal in pdf
(older numbers) require 512M of RAM to render on Intel laptop!
This exposed small bug in checkcache which checked just page no
which didn't get invalidated when closing page, so we now check if page
is also not nil
The sources can now conditionally compile emulation code
for the e-ink framebuffer and input events.
It uses SDL for doing that, so you need this installed
if you want to use emulation (you do not need it if you're
only compiling for the e-ink device).
This allows for rapid testing of new code.
usage in Lua:
dc:setGamma(1.5)
print(dc:getGamma())
set it to a negative value to disable gamma correction
(since gamma correction will always imply calculations
over the full buffer data).
