| Age | Commit message (Collapse) | Author |
|---|
|
The check for width and height being stupidly large
solves a SEGV that shows up while fuzzing.
|
|
|
|
This is faster on ARM in particular. The primary changes involve
fz_matrix, fz_rect and fz_bbox.
Rather than passing 'fz_rect r' into a function, we now consistently
pass 'const fz_rect *r'. Where a rect is passed in and modified, we
miss the 'const' off. Where possible, we return the pointer to the
modified structure to allow 'chaining' of expressions.
The basic upshot of this work is that we do far fewer copies of
rectangle/matrix structures, and all the copies we do are explicit.
This has opened the way to other optimisations, also performed in
this commit.
Rather than using expressions like:
fz_concat(fz_scale(sx, sy), fz_translate(tx, ty))
we now have fz_pre_{scale,translate,rotate} functions. These
can be implemented much more efficiently than doing the fully
fledged matrix multiplication that fz_concat requires.
We add fz_rect_{min,max} functions to return pointers to the
min/max points of a rect. These can be used to in transformations
to directly manipulate values.
With a little casting in the path transformation code we can avoid
more needless copying.
We rename fz_widget_bbox to the more consistent fz_bound_widget.
|
|
|
|
Inside the renderer we often deal with integer sized areas, for
pixmaps and scissoring regions. Use a new fz_irect type in these
places.
|
|
|
|
This means that repeated scaling of the same pixmap (or scales of
'stacked' pixmaps) will do less needless recalculation.
|
|
|
|
|
|
Attempt to separate public API from internal functions.
|
|
On extreme downscales, the weights for each pixel can all round to
zero; this results in no weights being stored at all, and causes
either an exception or a SEGV. The simple fix is to ensure that the
first pixel that's actually in range (and there will always be one)
always has a weight of at least 1.
Thanks to malc for finding the test cases that lead to this bugfix.
|
|
The ARM optimised code relied on the size of the weights structure
which was changed by the addition of a new member as part of the
patch scaling changes. Fix the code here, and add a note to the
structure in the hopes that this will avoid such breakages happening
in future.
|
|
|
|
|
|
When scaling a bitmap, currently we always scale the entire bitmap,
even if we only need a small section of the result.
This patch changes the code to take an optional 'clip' bbox, and
only scales as many pixels as are required to generate the required
output region.
|
|
This reverts commit 08e84b18e5c1dbe8f3d32dd0aeb4b4c43debce9f.
|
|
When scaling a bitmap, currently we always scale the entire bitmap,
even if we only need a small section of the result.
This patch changes the code to take an optional 'clip' bbox, and
only scales as much of the input as as required for this output
region.
|
|
|
|
Also: use 'cannot' instead of 'failed to' in error messages.
|
|
Mostly redoing the xps_context to xps_document change and adding
contexts to newly written code.
Conflicts:
apps/pdfapp.c
apps/pdfapp.h
apps/x11_main.c
apps/xpsdraw.c
draw/draw_device.c
draw/draw_scale.c
fitz/base_object.c
fitz/fitz.h
pdf/mupdf.h
pdf/pdf_interpret.c
pdf/pdf_outline.c
pdf/pdf_page.c
xps/muxps.h
xps/xps_doc.c
xps/xps_xml.c
|
|
Extract the grid fitting code from the scaling code and the affine image
drawing code into it's own separate function. This reduces code
duplication. It also allows us to make better allowance for rounding
errors.
Add a voodoo offset in the draw_affine.c code for painting interpolated
images. This gives us the best possible match between all the different
combinations of scaled/unscaled and interpolated/uninterpolated images.
|
|
Kammerer reports 90%+ of CPU time is spent in the image scaling code
for his documents on Android.
In this commit we provide ARM optimised cores for the common scaling
routines (1/2/4 components). Tests indicate this doubles the speed of
rendering for a bitmap heavy PDF file on an HTC desire.
This code is included if ARCH_ARM is defined. If ARCH_THUMB is defined
then extra instructions are added to ensure correct interworking.
We also update the Android jni makefiles to set these defines.
We update the ReadMe.txt with more explicit instructions and update with
more modern ndk/sdk versions.
We update build.xml in line with new sdk releases.
|
|
|
|
Huge pervasive change to lots of files, adding a context for exception
handling and allocation.
In time we'll move more statics into there.
Also fix some for(i = 0; i < function(...); i++) calls.
|
|
To solve bug 691629 we need to ensure that the scaling weights for
every pixel in a gridfitted image sum to 256. I had attempted to
do that by enabling the 'WRAP' code, but this has the effect of
adding too much bias to the outlying source pixels, resulting in
thickened serifs etc.
A better fix is to extend the code that is already present to check
the weights for validity. If an image pixel is completely covered,
then force the weights to 256 by adjusting the largest weight.
This still skews the output slightly but it's a much less visible
result.
|
|
When we calculate weights for scaling, 'wrap' weight calculations
slightly to avoid getting antialiased edge pixels in grid fitted
images.
Seems to solve bug 691629 as much as it's possible to.
|
|
The problem is due to abutting images showing gaps between them.
These gaps are due to a combination of rounding errors, and anti-aliasing
effects on the edge of images.
The solution is to selectively 'grid fit' images.
If an image is part of a type 3 font, we do NOT want to grid fit it, as
this is where the sub pixel positioning makes a huge difference.
If an image is displayed with alpha, then we don't want to grid fit it
(as grid fitting will tend to make the edges of images overlap by 1
pixel, and will hence produce nasty effects).
Otherwise, we will grid fit; Grid fit in this sense is where we expand
an image to completely fill the pixel grid that it touches (i.e. the
extents for the image are expanded to pixel boundaries; no half full
pixels are left around the edges).
The only real change of note here is in how we detect that we are in a
type 3 charproc; we add a new draw device creation function that we call
in the type3 charproc case that sets a flag that the drawing functions
can check.
|
|
Thanks to Zeniko for finding/reporting/patching the problem.
Due to a pointer miscalculation we were overwriting memory. Simple fix.
|
|
|
|
The run-together words are dead! Long live the underscores!
The postscript inspired naming convention of using all run-together
words has served us well, but it is now time for more readable code.
In this commit I have also added the sed script, rename.sed, that I used
to convert the source. Use it on your patches and application code.
|
|
|
