the framebuffer "object" now has a "member" that exposes the blitbuffer
API for the framebuffer pixmap. This allows to reuse blitting & Co for
blitbuffer-to-blitbuffer operations
this allows to render glyphs and also brings a simple
engine for rendering UTF-8 strings onto the framebuffer.
blitting to uneven offset is implemented here, too, but
needs more work and is still buggy.
In the end, this will allow for a simple GUI.
This works only in ZOOM_BY_VALUE mode invoked by Shift+Page< or Shift+Page>
Panning is modal: in normal mode, you move using fiveway but
when you press fiveway you switch to move-by-screen mode
(which is useful after you centered first column of article
and you just want to move around)
At any time you can press fiveway with shift to move in even smaller
increments
also, added key codes from launchpad sources.
thus, a few constants change their names.
These are the current keys:
PGFWD = next page
PGBCK = previous page
SHIFT+PGFWD = zoom in
SHIFT+PGBCK = zoom out
A = fit to page
S = fit to page width
D = fit to page height
SHIFT+A = fit to page content
SHIFT+S = fit to page content width
SHIFT+D = fit to page content height
SHIFT+FW_UP = Gamma + 0.2
SHIFT+FW_DOWN = Gamma - 0.2
in order to use the tile cache for variable zoomed tiles, we need more
flexibility. thus, now cache tiles are hashed (well, in fact it's a
concatenation) of their metadata.
also, we close pages right after opening them - there was no re-use
before and now we have opening and closing at one place. this should
also make it easier for the garbage collector.
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.
