Age | Commit message (Collapse) | Author |
|
|
|
Patch from "andyhan2000" to make the ink annotations smoother.
|
|
Thanks to Goncalo Ferreira(*) (aka monxalo) for this patch.
Firstly, we move our textured background off the layout and into a
style applied to MuPDFActivity. By using "windowBackground", we
avoid the default background being redrawn only to be overlaid
with ours. This cuts out one level of overdrawing.
Secondly, when drawing each PageView, the old code would render the
background for the page, then would draw the bitmap over the top of
that. While it's important to draw the background of the page before
we have a bitmap for the page, we can avoid that stage once a page
bitmap arrives.
(* apologies for not being able to put the cedilla on the 'c' in your
name, but git gives problems with top bit set chars.)
|
|
|
|
Highlight annotations currently come out opaque so aren't a lot of use.
|
|
Also change the way we pass the text rectangles so that
non-axis-aligned ones can be permitted, and relocate the code that
calculates the strike-out lines from the bounding boxes
|
|
|
|
|
|
This change showed up a bug where highlights may fail to show if passed
in while the page was set as blank. That bug is also fixed in this commit
|
|
|
|
|
|
ClipboardManager changed its API at Honeycomb, AnimatorInflater only
appeared at Honeycomb. Both of these are used by the clipboard code.
Add fallback code to work with the older systems on older devices.
|
|
After much discussion and investigation, Paul and I have realised
that we do in fact (in the current scheme at least) need to hold
the existing bitmap in memory while drawing the next one (as the
existing bitmap is still in an ImageView and being used for any
foreground render requests). As such remove a 'setBm(null)' in
drawPage.
Also, in the onPostExecute for the patch redraw, we cannot recycle
the bitmap in a bitmap holder due to it still potentially being
in use. We therefore add a 'drop' method to the BitmapHolder class
that sets the reference to null without recycling. This is not
ideal, but is better than recycling too early and causing crashes.
|
|
Due to a clash on Google Play, we need to rename the apps main
class from com.artifex.mupdf to something else. We choose
com.artifex.mupdfdemo. Any user of the code in their own app
should rename it similarly. To simplify this process we add
some macros in the C.
Various renames and lots of tedious package name editing is still
required in the Java though.
|