| Age | Commit message (Collapse) | Author |
|---|
|
The code attempts to spot cases where a pattern tile is so large that
only 1 repeat is visible. Due to rounding errors, this test could
sometimes fail, and (on badly formed files) we'd attempt to allocate
huge pixmaps.
The fix is to allow for rounding errors.
|
|
In builds that support configurable layers of antialiasing, move
the variables that control this into the context. This makes it
possible to safely use different levels of antialiasing in different
threads.
|
|
|
|
Previously, we had a hardwired 96 element stack for clipping/group
nesting etc. If this was exceeeded during rendering we would give
an error.
Now we allow for that stack to be extended dynamically at runtime.
If the stack extension fails, we will give an error and die.
|
|
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.
|
|
draw_simple_scale.c is a cut down version of draw_scale.c, that only
uses filter functions that return values strictly in the 0 to 1 range.
Because of that, we can use bytes rather than ints as intermediate
storage, and have no clipping to do.
|
|
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.
|
|
Until such time as the knockout and isolated group support is known to
work properly, leave it disabled so we behave the same as we have until
now.
|
|
|
|
|
|
|
|
|
|
In an effort to solve bug 692377, examine what ghostscript does,
and move mupdf into line with it.
Firstly, it seems that rather than collecting a pure 'shape' plane
ghostscript keeps a 'shape-with-alpha' plane. Only a tiny change is
required to move mupdf to the do the same thing, so done here.
Secondly, it seems that ghostscript 'uncomposites' the result of
non-isolated groups, before applying the blend mode. It's not clear
to me that this is entirely correct; this 'uncomposite' operation
assumes that all compositing has been done internally with the
'normal' blend mode. Nonetheless, I do the same here, and it seems
to work.
This 'uncomposite' operation may yet turn out to be a source of bugs
if I have muddled the use of premultiplied and non-premultiplied
components, but it seems to work on the testfiles I have.
|
|
Comment #3 on bug 692377 notes that the "Hivemind" pdf (from bug
692203) has regressed; this is due to the new shape code not
working quite right with mask groups. Fixed here.
It also showed up a bug in the shape code with filled paths at non
full alpha. Also fixed.
In tracking this down, I've extended the DUMP_GROUP_BLENDS debugging
code to give more readable output. Also committed here.
This still leaves a regression in l16.pdf which the bug was originally
reopened about, but that's a much more minor one.
|
|
All glyphs in type3 colored fonts were drawn mirrored in y due to
an incorrectly setup transformation matrix.
The bug was reported by Zeniko, with a helpful example file that showed
the problem.
Until then I'd been working using only fts_23_2303.pdf as an example,
which uses geometric shapes, so isn't obvious that it's wrong. Also
my copy of acrobat fails to render them.
|
|
Some code that I find useful for debugging the group blending code.
|
|
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.
|
|
A combination of constant alpha and non-zero blending modes resulted
in incorrect rendering.
Various fixes seem to have made it work:
* Allow for non-full alpha when blending non-isolated groups back.
* Clamp blended pixels to allow for overflow.
* Allow for alpha in the shape blending.
|
|
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.
|
|
Detect the d0 or d1 operators by writing a bit to the new device
flags word. This can then be checked by the Type3 code to create
the appropriate backing pixmap.
In order to know what the appropriate backing pixmap is, we pass
an additional colorspace into the glyph rendering code.
|
|
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.
|
|
While in a knockout group, we create a new group around every single
object drawn. These groups are either isolated or non-isolated as
required (but non-isolated ones seed their background from two
backgrounds up the stack, not one).
|
|
Firstly, this takes on some of Zenikos patch to correct the clip
stack handling that was broken by the fix to bug 692287 (in commit
2c3bbbf). This bug should now be solved.
We add a new 'shape' field to the draw device structure (and clip
stack). When we are inside non-isolated groups, this is set to be
a pixmap where we accumulate the 'shape' of the objects drawn.
When we come to blend back, if we are blending a non-isolated group
back, we have to use a different blending function that takes account
of the shape.
Various internal groups (the page group, and groups used to force
blending) are set to be isolated to avoid carrying shape planes
around when this is not required.
All our rendering code now has to know how to maintain the shape
plane as well as doing the basic rendering.
|
|
First, we add clipping rects to clipping functions. Various functions
(the ones that handle clipping) are now additionally passed a rectangle
that represents an additional bound for this clip in device space
(i.e. it has already been mapped through the current ctm).
Next, when constructing the displaylist, keep track of the bounding box
for the contents of each clip.
While writing the list, on every node we add, we add the bbox for that
node to the enclosing clips content bbox (if there is an enclosing clip).
When we pop a clip, write back to the corresponding push to update
the bbox.
This means if we get large clip regions, with only small areas used within
them, we will only do the slow blending for those small areas.
Finally, we fix a calculation in fz_bound_path which was incorrectly
accounting for mitrelimits. This was showing up in testing on page 630
of the PDF reference v1.7.
|
|
Thanks to Zeniko for finding/reporting/patching the problem.
Due to a pointer miscalculation we were overwriting memory. Simple fix.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Also put the function on the same line for inline functions, so
they stick out and are easy to find with grep.
|
|
Also turn on font hinting when rendering non-aa text.
|
|
AA_BITS < 0 => Runtime configurable.
AA_BITS = 0 => No antialiasing
AA_BITS > 0 => At least that many bits of accuracy (to a max of 8).
If unspecified, default is 8, so old behaviour is maintained.
|
|
|
|
|
|
|
|
New code to render grayscale images on an rgb device without converting
to rgb first.
|
|
|
|
They test for NULL and make the code look nicer.
|
|
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.
|
|
|
|
|
|
|
|
|
