Enaling link time optimizations for kpdfview binary and crengine library
causes another slight performance increase --- almost negligible (1-2ms
per page) but still noticeable by precise measurements.
Thanks to NiLuJe who pointed out that our generic -march=armv6 can be
replaced (for K2/K3/DX/DXG) with a more specific optimization:
-march=armv6j -mtune=arm1136jf-s -mfpu=vfp. This I have now done and
also passed ARM_CFLAGS value to CXXFLAGS which is then passed to
crengine build. Tested, works fine. The performance improvement is
negligible (a few ms per page, but seems to be consistently better, i.e.
not just plus/minus fluctuations).
Thanks to NiLuJe who pointed out that we are building mupdf in debug
mode. Switching to "release" build reduced the size of the kpdfview
binary and did not cause any performance degradation (but no noticeable
improvement either --- the page handling times seem to be exactly the
same, i.e. fluctuating a couple of ms in both directions).
This is a better version of the previous commit, which:
a) makes the code more readable
b) disallows rcountmax values like "6.05", i.e. restricts to integers
only.
1. ATM, the footers in selectmenu.lua & helppage.lua are left-adjusted,
these also contain the prompt for users how to call help
(selectmenu.lua) and how to go back (helppage.lua). By minor correction
to function DrawFooter() in filechooser.lua, one may readily make the
rest footers to look in a similar way.
2. When writing the code of inputbox.lua, I (NuPogodi) left the wrong
command to delete the 1st entry in the math function list
(called in calculator mode by pressing Alt-M).
The printf() about the number of links on a page is very useful, but
only for debugging. As other instances of debugging printf() in djvu.c
and pdf.c are commented out, it seemed consistent to do the same with
this one.
1. Remove unused "-lsdtc++" from the compilation stage as no linking is
done then.
2. Add our standard CFLAGS to the compilation of cre.cpp which brings in
-O3 -march=armv6 which enables optimizations.
It seemed strange that we compile a cpp file with gcc (as opposed to
g++), but I left it as is for now.
Store last globalzoom_mode in self.pan_by_page so we can restore it
to force offsets recalculation on page change
This wasn't quite enough to trigger correct re-panning for page
changes when using fiveway to move in two-column mode, issue #275
I considered adding callback to goto method and than transfering
it through function calls, but this approach (allthough very
questionable) seemed to provide simplier code.
This fix makes the behaviour of Back command handler in crereader
identical with that in unireader, i.e. the last position is saved in
Jump History when pressing Back, so you can return to it by pressing
Shift-Back enough times.
Also, with this change we would need to handle the need for redrawing
the current page because the :addJump() method can force the call to
fillToc() (if TOC is not already present) and this will display
"Retrieving TOC..." message which will need clearing away.
Store last globalzoom_mode in self.pan_by_page so we can restore it
to force offsets recalculation on page change
This wasn't quite enough to trigger correct re-panning for page
changes when using fiveway to move in two-column mode, issue #275
I considered adding callback to goto method and than transfering
it through function calls, but this approach (allthough very
questionable) seemed to provide simplier code.
For PDF and DjVu files (but not for crereader) the command handler for
"Back" key can call addJump() in order to avoid losing the top of the
jump history on return. This (addJump()) can cause the TOC to be
retrieved and the message "Retrieving TOC..." to be displayed.
If this happens then we need to redraw the current page after displaying
our own "Already first jump!" message.
1. Remove unused assert() around io.open of the input device. The failure
to open input device is already guarded by the "if inputf" code.
2. Remove unneeded assert() around io.open of the output device. This is
unneeded because we should not crash the whole application just because
we cannot write screen dump (e.g. because filesystem is full, etc) ---
rather we should exit gracefully.
