| Age | Commit message (Collapse) | Author |
|---|
|
Inspired by Sumatras gdi devices need for such a function expose
the blending functions. Note that we produce unsigned char's
where Zenikos original produces ints, but it's otherwise
identical.
This requires us to make various knockon changes throughout the code
from int to unsigned char, none of which should make any difference
at all - I hope!
We reserve the right to change/amend this function in future to
operate on blocks of pixels (or pixels in different colorspaces)
(or anything else we think of) in future.
|
|
|
|
Take on a modified version of Zenikos patch; only take the quick
exit if the whole dash length is small, or if the dash_length
scaled up by the maximum possible scale in the ctm is less than
1/2 a pixel.
|
|
Various fixes to avoid overflow problems, division by zeros, use
of uninitialised variables etc. All from/suggested by Zenikos patch.
|
|
Thanks to Zeniko for pointing this out.
|
|
Only create a shape if we need to.
Correctly cleanup, thus avoiding a double free of mask later on.
Thanks to Zeniko for spotting these.
|
|
As we create clips/transparency groups etc, we maintain a stack of
draw device states.
Here we change this from having a 'current' state, and storing changes
on the stack to always keeping the complete current state on the head
of the stack. This should make error cleanup easier, as well as being
conceptually easier to follow (for me at least).
|
|
When starting to tile, create a shape plane if one exists.
When finishing tiling, plot the shape plane back too.
This solves the SEGVs. Something isn't quite right with the blending
colours on part of this file though.
|
|
Testsseem to indicate that this works, and gives noticable
improvements. Enabling by default.
|
|
The shape plane was being incorrectly offset from the dest plane.
This could have caused SEGVs or incorrect results when blending
back.
This solves the hivemind.pdf iphone being clipped on the right hand
side.
|
|
More work on MuPDFs blending support. This seems to get l16.pdf
working pretty well. Fuller testing required to know if we get
everything right, but the maths now makes as much sense as it
ever has to me, and seems to track what gs does (more or less,
in that we don't use group alpha and gs does).
|
|
As Zeniko correctly points out in bug 692593, I had incorrectly
used hp[n1] when I should be using hp[0] at various points.
Hopefully that bug should be solved in it's entirety now with
the previous commit.
|
|
Restrict images to the size of the shape when blending back.
This seems to solve the problem; leaving code disabled until full
tests complete.
|
|
|
|
|
|
|
|
|
|
The new fz_malloc_struct(A,B) macro allocates sizeof(B) bytes using
fz_malloc, and then passes the resultant pointer to Memento_label
to label it with "B".
This costs nothing in non-memento builds, but gives much nicer
listings of leaked blocks when memento is enabled.
|
|
Fixes for leaks (and SEGVs, division by zeros etc) seen when
Memsqueezing.
|
|
Also: use 'cannot' instead of 'failed to' in error messages.
|
|
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.
|
|
|
