| Age | Commit message (Collapse) | Author |
|---|
|
As requested by customer 530.
|
|
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).
|
|
|
|
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.
|
|
|
|
|
|
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!
|
|
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.
|
|
This means that repeated scaling of the same pixmap (or scales of
'stacked' pixmaps) will do less needless recalculation.
|
|
|
|
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.
|
|
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.
|
|
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.
|
|
|
|
When we allocate a pixmap > 2G, but < 4G, the index into that
pixmap, when calculated as an int can be negative. Fix this with
various casts to unsigned int.
If we ever move to support >4G images we'll need to rejig the
casting to cast each part of the element to ptrdiff_t first.
|
|
Restricts rendering to a sub rectangle of the supplied bbox.
|
|
Currently all conversions from rect to bbox are done using a single
function, fz_round_rect. This causes problems, as sometimes we want
'round, allowing for slight calculation errors' and sometimes we
want 'round slavishly to ensure we have a bbox that covers the rect'.
We therefore split these 2 cases into 2 separate functions;
fz_round_rect is kept, meaning "round outwards allowing for slight
errors", and fz_bbox_covering_rect is added to mean "give us the
smallest bbox that is guaranteed to cover rect".
No regressions seen.
|
|
Taken from Sumatra.patch - Many thanks.
|
|
|
|
Debug printing functions: debug -> print.
Accessors: get noun attribute -> noun attribute.
Find -> lookup when the returned value is not reference counted.
pixmap_with_rect -> pixmap_with_bbox.
We are reserving the word "find" to mean lookups that give ownership
of objects to the caller. Lookup is used in other places where the
ownership is not transferred, or simple values are returned.
The rename is done by the sed script in scripts/rename3.sed
|
|
C's standard is copy(dst, src), so we move to adopt that here.
Hopefully no one is calling this routine other than us - if they are,
then I apologise! Better to aim for consistency before we freeze
the API at v1.0 than to carry an inconsistent API around ever after.
|
|
C's standard is copy(dst, src), so we move to adopt that here.
Hopefully no one is calling this routine other than us - if they are,
then I apologise! Better to aim for consistency before we freeze
the API at v1.0 than to carry an inconsistent API around ever after.
|
|
|
|
In the cancel or error case, we cleanup pixmaps left on the
draw devices stack. We were cleaning up one layer more in
the error code than in normal code, leading to a double free.
|
|
Attempt to separate public API from internal functions.
|
|
Introduce a new 'fz_image' type; this type contains rudimentary
information about images (such as native, size, colorspace etc)
and a function to call to get a pixmap of that image (with a
size hint).
Instead of passing pixmaps through the device interface (and
holding pixmaps in the display list) we now pass images instead.
The rendering routines therefore call fz_image_to_pixmap to get
pixmaps to render, and fz_pixmap_drop those afterwards.
The file format handling routines therefore need to produce
images rather than pixmaps; xps and cbz currently just wrap
pixmaps as images. PDF is more involved.
The stream handling routines in PDF have been altered so that
they can recognise when the last stream entry in a filter
dictionary is an image decoding filter. Rather than applying
this filter, they read and store the parameters into a
pdf_image_params structure, and stop decoding at that point.
This allows us to read the compressed data for an image into
memory as a block. We can then restart the image decode process
later.
pdf_images therefore consist of the compressed image data for
images. When a pixmap is requested for such an image, the code
checks to see if we have one (of an appropriate size), and if
not, decodes it.
The size hint is used to determine whether it is possible to
subsample the image; currently this is only supported for
JPEGs, but we could add generic subsampling code later.
In order to handle caching the produced images, various changes
have been made to the store and the underlying hash table.
Previously the store was indexed purely by fz_obj keys; we don't
have an fz_obj key any more, so have extended the store by adding
a concept of a key 'type'. A key type is a pointer to a set of
functions that keep/drop/compare and make a hashable key from
a key pointer.
We make a pdf_store.c file that contains functions to offer the
existing fz_obj based functions, and add a new 'type' for keys
(based on the fz_image handle, and the subsample factor) in the
pdf_image.c file.
While working on this, a problem became apparent in the existing
store codel; fz_obj objects had no protection on their reference
counts, hence an interpreter thread could try to alter a ref count
at the same time as a malloc caused an eviction from the store.
This has been solved by using the alloc lock as protection. This in
turn requires some tweaks to the code to make sure we don't try
and keep/drop fz_obj's from the store code while the alloc lock is
held.
A side effect of this work is that when a hash table is created, we
inform it what lock should be used to protect its innards (if any).
If the alloc lock is used, the insert method knows to drop/retake it
to allow it to safely expand the hash table. Callers to the hash
functions have the responsibility of taking/dropping the appropriate
lock, and ensuring that they cope with the possibility that insert
might drop the alloc lock, causing race conditions.
|
|
|
|
|
|
|
|
|
|
fz_draw_fill_image_mask was improperly nesting group start/ends, by
calling fz_knockout_start at the top, and then fz_knockout_start
again at the end. Changing this latter one to fz_knockout_end
solves the problem.
Also tweak the debugging code slightly to give more readable results.
|
|
The cluster testing of MuPDF repeatedly crashes on
pdf/PDF_1.7_FTS/fts_20_2008.pdf. Investigation shows this is because
we fail to write the newly allocated mask back to the graphics
state stack when starting a clip_stroke_text drawing operation.
This causes later pops to fall over.
Simple fix.
|
|
Both Zeniko and Malc have said that this causes problems.
Following a hint from malc, the following command causes the
assert to trigger:
win32/Debug/pdfdraw.exe -r0.3 -o out.png ../MyTests/pdf_reference17.pdf 1143
I suspect it's because of the extreme resolution, and the round_rect
call. At any rate, disabling the assert is of no real import.
|
|
|
|
When scaling a bitmap, currently we always scale the entire bitmap,
even if we only need a small section of the result.
This patch changes the code to take an optional 'clip' bbox, and
only scales as many pixels as are required to generate the required
output region.
|
|
This reverts commit 08e84b18e5c1dbe8f3d32dd0aeb4b4c43debce9f.
|
|
When scaling a bitmap, currently we always scale the entire bitmap,
even if we only need a small section of the result.
This patch changes the code to take an optional 'clip' bbox, and
only scales as much of the input as as required for this output
region.
|
|
|
|
|
|
|
