| Age | Commit message (Collapse) | Author |
|---|
|
The check for width and height being stupidly large
solves a SEGV that shows up while fuzzing.
|
|
|
|
To prepare for color management, we have to make the device colorspaces
per-context and able to be overridden by users.
|
|
Pass stroke state into fz_bound_text to allow for stroked text.
Simplifies some calling code.
Add consts to clarify the meanings of the calls.
|
|
Trace edges using floating point without pulling onto pixels.
Use fixedpoint for colors.
|
|
|
|
Add some more consts's and use void *'s where appropriate.
|
|
As requested by customer 530.
|
|
Avoid needless copies. Thanks to Christophe from customer 530 for
the original version of this patch.
Also tweak clipx and clipy so that both intersection calculations
in each rotuine are identical.
|
|
Some -Wshadow ones, plus some 'set but not used' ones.
|
|
|
|
This requires a slight change to the device interface.
Callers that use fz_begin_tile will see no change (and no caching
will be done). We add a new fz_begin_tile_id function that takes an
extra 'id' parameter, and returns 0 or 1. If the id is 0 then the
function behaves exactly as fz_being_tile does, and always returns 0.
The PDF and XPS code continues to call the old (uncached) version.
The display list code however generates a unique id for every
BEGIN_TILE node, and passes this in.
If the id is non zero, then it is taken to be a unique identifier
for this tile; the implementer of the fz_begin_tile_id entry point
can choose to use this to implement caching. If it chooses to ignore
the id (and do no caching), it returns 0.
If the device implements caching, then it can check on entry for a
previously rendered tile with the appropriate matrix and a matching id.
If it finds one, then it returns 1. It is the callers responsibility
to then skip over all the device calls that would usually happen to
render the tiles (i.e. to skip forward to the matching 'END_TILE'
operation).
|
|
|
|
The recent positioning fix for bug 693640 caused a problem with rotated
images. The fix is to only apply the previous fix when we have rectilinear
scalings of images.
|
|
When calculating the texture position for interpolated painting we
apply a voodoo correction. This was causing problems by taking us
out of bounds; simply add some checks to avoid this taking us out
of range.
This causes many differences, all small, or progressions. In particular
it solves several 'white lines' cases where images didn't quite
line up.
|
|
Avoid heap overflow in the error case in fz_end_tile.
Avoid leaking all previously loaded annotations from pdf_load_annots
if pdf_is_dict throws an exception.
Various whitespace fixes.
Many thanks to zeniko.
|
|
|
|
|
|
Also, move fz_is_infinite_rect and fz_is_empty_rect to be a static
inline rather than a macro. (Static inlines are preferred over
macros by at least one customers).
We appear to be calling them with bboxes too, so add fz_is_infinite_bbox
and fz_is_empty_bbox to solve this.
|
|
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.
|
|
|
|
|
|
It used to be called fz_bbox_covering_rect. It does exact rounding outwards
of a rect, so that the resulting irect will always cover the entire
area of the input rect.
Use fz_round_rect for fuzzy rounding where near-integer values are
rounded inwards.
|
|
Inside the renderer we often deal with integer sized areas, for
pixmaps and scissoring regions. Use a new fz_irect type in these
places.
|
|
|
|
|
|
When I optimised sharp edge rendering back in commit 720859d,
I made a mistake that can result in broken renderings.
Fixed here. Thanks for Dan Waleke for reporting this.
|
|
Two problems with tiling are fixed here.
Firstly, if the tiling bounds are huge, the 'patch' region (the region
we are writing into), can overflow, causing a SEGV due to the paint code
being very confused by pixmaps that go from just under INT_MAX to just
over INT_MIN. Fix this by checking explicitly for overflow in these
bounds.
If the tiles are stupidly huge, but the scissor is small, we can end up
looping many more times than we need to. We fix mapping the scissor
region back through the inverse transform, and intersecting this
with the pattern area.
Problem found in 4201.pdf.SIGSEGV.622.3560, a test file supplied by
Mateusz "j00ru" Jurczyk and Gynvael Coldwind of the Google Security
Team using Address Sanitizer. Many thanks!
|
|
When calculating the bbox for draw_glyph, if the x and y origins of
the glyph are extreme (too large to fit in an int), we get overflows
of the bbox; empty bboxes are transformed to large ones.
The fix is to introduce an fz_translate_bbox function that checks for
such things.
Also, we update various bbox/rect functions to check for empty bboxes
before they check for infinite ones (as a bbox of x0=0 x1=0 y0=0 y1=-1
will be detected both as infinite and empty).
Problem found in 2485.pdf.SIGSEGV.2a.1652, a test file supplied by
Mateusz "j00ru" Jurczyk and Gynvael Coldwind of the Google Security
Team using Address Sanitizer. Many thanks!
|
|
With a small dst_w (e.g. 1e-23) the floating point maths governing
scales can go wrong in the weight calculations. MSVC in particular
seems to return 1<<31 for the result of the max_len calculation.
It makes no real sense to scale bitmaps to < 1 pixel, so simply clamp
width and height as required.
Problem found in 2923.pdf.asan.22.2139, a test file supplied by
Mateusz "j00ru" Jurczyk and Gynvael Coldwind of the Google Security
Team using Address Sanitizer. Many thanks!
|
|
When extreme ranges (+/- MAX_INT) are passed into the scaler
signed wrap around gives us problems when calculating the patch.
Simply ignore such cases.
Problem found in 1792.pdf.SIGSEGV.387.883, a test file supplied by
Mateusz "j00ru" Jurczyk and Gynvael Coldwind of the Google Security
Team using Address Sanitizer. Many thanks!
|
|
Whenever we have an error while pushing a gstate, we run the risk of
getting confused over how many pops we need etc.
With this commit we introduce some checking at the dev_null level that
attempts to make this behaviour consistent.
Any caller may now assume that calling an operation that pushes a clip
will always succeed. This means the only error cleanup they need to
do is to ensure that if they have pushed a clip (or begun a group, or
a mask etc) is to pop it too.
Any callee may now assume that if it throws an error during the call
to a device entrypoint that would create a group/clip/mask then no more
calls will be forthcoming until after the caller has completely finished
with that group.
This is achieved by the dev_null layer (the layer that indirects from
device calls through the device structure to the function pointers)
swallowing errors and regurgitating them later as required. A count is
kept of the number of pushes that have happened since an error
occurred during a push (including that initial one). When this count
reaches zero, the original error is regurgitated. This allows the
caller to keep the cookie correctly updated.
|
|
Thanks to zeniko for the heads up.
|
|
Add a mechanism for getting a color converter function. Implement
the 'convert a single color' call in terms of that. 'Bulk' users
can then repeatedly call the single function.
|
|
In doing this work, it strikes me that there is an unoptimised case
left in the aa scan conversion; when we are plotting whole scanlines
with gel->alen = 0, we can skip the entire blit. This happens
relatively rarely so the extra cost of the test may be more than
is worthwhile.
|
|
Currently the scan converter advances one 'subpixel' scanline at a
time; here we update it to work in multiple subpixel scanlines at a
time.
If we spot that the gel consists of entirely vertical edges, then we
calculate the height for which those edges will remain unchanged. This
allows us to deal quickly with rectangular paths.
In the case of large vertical only edges, we can process multiple
scanlines (not just subpixel scanlines) at once.
|
|
This means that repeated scaling of the same pixmap (or scales of
'stacked' pixmaps) will do less needless recalculation.
|
|
By manually inserting a literal pool, we can avoid the need to
split draw_simple_scale.c out.
|
|
Move the assembly macros into fitz-internal.h.
|
|
|
|
This avoids a stall, and saves time on repeated loops.
|
|
Requires android-ndk-profiler to be copied into android and android/jni.
Also requires r8c of the NDK.
|
|
When shutting down a draw device, we were not freeing pixmaps all
the way down the stack. Tweaked code to hopefully be clearer
when I come back to read it again.
Thanks to zeniko for pointing this out.
|
|
Previously these were only used for shadings in test builds.
By the same argument that they are applied for shadings, it
can be argued that they ought to be applied everywhere trig
functions are used.
|
|
|
|
Currently, the mupdf code loads shadings at parse time, and
instantly decomposes them into a mesh of triangles. This mesh
of triangles is the transformed and rendered as required.
Unfortunately the storage space for the mesh is typically much
greater than the original representation.
In this commit, we move the shading stream parsing/decomposition
code into a general 'fz_process_mesh' function within res_shade.
We then grab a copy of the buffer at load time, and 'process'
(decompose/paint) at render time.
For the test file on the bug, memory falls from the reported 660Mb
to 30Mb. For another test file (txt9780547775815_ingested.pdf
page 271) it reduces memory use from 750Meg to 33Meg. These figures
could be further reduced by storing the compressed streams from the
pdf file rather than the uncompressed ones.
Incorporating typo fix and unused function removal from Sebras. Thanks.
Remove unused function in shading code
|
|
We'd never got around to implementing text clipping with oversized
glyphs before, at least partly due to a lack of files showing the
problem. Now, thanks to a file from Paul Hudson, we have an
example and hence a fix.
|
|
Variable i can never be zero at this point. The desired point of testing
against i was to ensure that the test did not evaluate true at the
first run, and the other parts of the condition are sufficent to
ensure this, so just remove the test on i.
|
|
Since the commit to replace abs/min/max/clamp with inline versions,
"1522 - diagramm missing above 88 pc zoom.pdf" has been missing a
diagram. This is because the diagram contains sections like:
-2147483648 -2147483648 m
-2147483648 2147483647 l
2147483647 2147483647 l
2147483647 -2147483648 l
These extreme values, when transformed would give floating point values
that when naively cast down to int, flip sign (e.g. extreme positive
when cast to int becomes extreme negative).
I had been relying on the cast down giving sane results to enable me to
use fz_clampi. Revert to using fz_clamp and all is fine.
|
|
The FT_Stroker doesn't support dash patterns. Fall back to the normal
path rendering, same as with glyphs that are too big to fit the cache.
|
