| Age | Commit message (Collapse) | Author |
|---|
|
We were failing to allow for the fact that the source pixmap
is premultiplied, meaning we were squaring the alpha each
time.
|
|
When pushing a transparency group, MuPDF used to always create a shape
plane if there was one before. Ghostscript works differently, and
only creates a shape plane if we are in a non-isolated group.
This means that when blending an isolated group back to a non
isolated group, GS uses the "source alpha" in place of the "shape
alpha" to modify the non-isolated groups shape plane.
We update MuPDF to do the same here - it requires some new (small)
routines to do this new type of shape update, but means we carry
smaller amounts of data around overall.
Also, for what little remains of my sanities sake, this helps by
making it easier to compare the debug output from the 2 different
renderers.
|
|
|
|
|
|
|
|
Introduce an fz_overprint bitmap (currently just a uint32_t,
but it'll grow to be an array of them if FZ_MAX_COLOR is
increased). Pointers to this are passed into all our
painting routines.
NULL means "Do what you've always done before, with no overprint".
non NULL, means that every set bit means "don't ever alter this
component".
We therefore set the overprint bitmap up according to the input
color/colorspace/colorparams before calling each routine.
|
|
|
|
If draw device is passed a pixmap with disabled separations, it
may have to push an extra group at the top to allow for the
actual rendering to properly happen in cmyk+spots, and then get
folded down at the end.
This pushing cannot happen at create time, due to it being
dependent on the defualt_cs settings. Accordingly, we push it
(just once) on the first drawing operation.
This means we need to be able to convert from "colorspace + set
of spots" to "different colorspace + different set of spots".
This in turn means we need to be able to drive lcms slightly
differently (to tell it whether to copy the spots unchanged
or not), so we have to amend the CMS interface code a bit for
that.
Currently we lack plotters to properly cope with plotting
images and shades with spots, so this will give a warning and
do nothing. To be filled in in future commits.
Ensure fz_get_icc_link accepts NULL to mean default color params.
Incorporates fixes from Michel Vrhel:
With transparency groups we can have RGB + spot pixmaps. When
drawing into those we need a mixture of colorant polarity. Ensure
that fz_convert_separation_colors takes account of this.
Fix C1 of Altona_Technical_1v1_x3.pdf (allow for output intent in
fz_clone_pixmap_area_with_different_seps).
|
|
The conditional is always == 255 here.
|
|
Spot colors were getting bogus (typically 0xcd)
alpha applied to them during drawing.
|
|
|
|
We were passing in the wrong source alpha value in one of the
plotter calls. This is not a call used in our standard builds,
hence us not having seen the problem before.
Credit to Sebastian for spotting the problem and suggesting the
fix.
|
|
Should be 0..256 not 0..1
|
|
|
|
Non rectangular clips are currently handled by rendering to a
'isolated' background, and then plotting that through a mask.
This runs into problems when the rendering needs to use non
standard blend modes that need to access the background
colors.
Instead, copy the background to the new pixmap, render to that
then plot that through the mask.
This simplifies the painting code, because we now never have
mismatched source and destination alphas.
|
|
Slightly revised blending, making use of the fact that we can
no longer overflow due to ma + masa <= 0x100.
|
|
|
|
As part of the blending calculations, we do:
dst = src * mask_alpha + dst * (1-mask_alpha.src_alpha)
We calculate mask_alpha as ma, and 1-mask_alpha.src_alpha as masa.
In full accuracy, we should never have ma + masa >= 1.
Unfortunately, with the formulation used in the painters at the
moment, we can. We therefore rejig the calculations slightly.
|
|
Used for the file from bug 697122. Makes a small improvement
overall. (31.3s to 31s for a cutdown file).
The equivalent code using 64bit operations is slower.
|
|
|
|
If we have a source alpha, and it's 0, then nothing to paint.
|
|
Spotted with:
mutool draw -A0 -r600 -o out.ppm J11_acrobat.pdf
|
|
Short circuit any attempt to paint a pixmap with zero alpha.
|
|
|
|
In C we can't have a label as the only thing in a block.
|
|
|
|
Introduce FZ_PLOTTER defines to set which defines we required.
Add FZ_ENABLE define to set which document handlers are built
by default.
|
|
|
|
Use do {} while(--w) rather than while(w--) {} as this safes a
test each time around the loop.
|
|
|
|
Again, mainly so profiling works nicely.
|
|
Use this for plotters so we can see which ones are being used
in any given build.
Build with -DTRACK_USAGE to enable.
|
|
Only do int to int copying if we have an int to copy from.
Also, when copying int to int, copy int32_t to int32_t to make
us more future proof.
|
|
Try and help C avoid pointer aliasing issues. Some of this may not
help at all. None of it should hurt though.
|
|
fz_pixmaps now have an explicit stride value. By default no change
from before, but code all copes with extra gaps at the end of the
line.
The alpha data in fz_pixmaps is no longer compulsory.
mudraw: use rgb not rgba (ppmraw), cmyk not cmyka (pkmraw).
Update halftone code to not expect alpha plane.
Update PNG writing to cope with alpha less input.
Also hide repeated params within the png output context.
ARM code needs updating.
|
|
|
|
|
|
|
|
|
|
To avoid having to duplicate a fairly large block of code several
times, use repeated inclusion of a header with some macros to
generate optimised glyph plotters.
|
|
We have optimised plotters for 2 and 4 components (i.e. greyscale
and rgb). Add equivalent ones for CMYK.
|
|
Rather than generating fz_pixmaps for glyphs, we generate fz_glyphs.
fz_glyphs can either contain a pixmap, or an RLEd representation
(if it's a mask, and it's smaller).
Should take less memory in the cache, and should be faster to plot.
|
|
Broken in recent optimisations.
|
|
|
|
If we want the alternative versions we can pull them out of git
later.
|
|
The 2 biggest hotspots in benchmarking on the Raspberry pi at
1200dpi.
|
|
|
