| Age | Commit message (Collapse) | Author |
|---|
|
|
|
In preparation for work on progressive loading, update the exception
handling scheme slightly.
Until now, exceptions (as thrown with fz_throw, and caught with
fz_try/fz_catch) have merely had an informative string. They have
never had anything that can be compared to see if an error is of
a particular type.
We now introduce error codes; when we fz_throw, we now always
give an error code, and can optionally (using fz_throw_message)
give both an error code and an informative string.
When we fz_rethrow from within a fz_catch, both the error code and
the error message is maintained. Using fz_rethrow_message we can
'improve' the error message, but the code is maintained.
The error message can be read out using fz_caught_message() and the
error code can be read as fz_caught().
Currently we only define a 'generic' error. This will expand in future
versions to include other error types that may be tested for.
|
|
|
|
|
|
|
|
In some cases, the existing code can leave the GLYPHCACHE lock held
if an error occurs during type3 rendering. Correct this oversight.
Thanks to zeniko for spotting the bug and providing a fix.
|
|
As seen in fts_15_1506.pdf
|
|
|
|
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.
|
