| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
|
|
Instead of using macros for min/max/abs/clamp, we move to using
inline functions. These are more typesafe, and should produce
equivalent code on compilers that support inline (i.e. pretty much
everything we care about these days).
People can always do their own macro versions if they prefer.
|
|
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.
|
|
Keep texture position calculations in floats as long as possible, as
prematurely dropping back to ints can cause overflows in the
intermediate stages that don't nicely cancel out.
The fix for this makes 2000 or so bitmap differences, most trivial, but
with some progressions.
|
|
The scale_row_from_temp code was broken. Firstly the rounding was wrong
in the 'bulk' case (not a big deal), but more importantly on
configurations where unaligned loads were not allowed (such as the nook),
we could still crash due to an incorrect test to avoid that code.
Thanks to Kammerer for the report, and testing of fixed version.
|
|
|
|
Once the shape was combined with the image in the file in question
the width/height drop to be below zero. Detect this case and bale.
File rendering looks fine.
|
|
See Bug 688655 for analysis of what we SHOULD be doing. The code changes
to do this are actually quite small.
Essentially, when we join we only draw the 'top' (or 'outer') join in a
join dependent way. The 'under' join was always joined as a bevel before
as this was easy. This produces bad effects when the lines have a
significant angle between them and a large linewidth.
The correct (i.e. matching Acrobat and others) way to work is to
join the bottom of the line via the centre point. The sole exception
to this is when drawing under beziers, as we don't want to make our
approximation-by-lines obvious.
All fixed in this patch.
|
|
If this is defined during building, we use our own sinf/cosf/atan2f
functions during shading. This is set automatically if CLUSTER is defined
too, so this should remove the cross-platform differences seen during
cluster rendering.
|
|
Restricts rendering to a sub rectangle of the supplied bbox.
|
|
Don't reset the size of arrays until we have successfully resized them.
|
|
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
|
|
Code was copying the wrong structure. Thanks to Pedro Rivera
for pointing this out.
|
|
|
|
In the existing code, glyphs are stored/retrieved from the glyphcache
with no reference to the antialias level used to create them. This
means that if we are using different aa levels in different threads,
we can retrieve 'non-matching' glyphs and hence get rendering
indeterminisms.
Fixed simply here by storing the aa level in the glyphcache too.
|
|
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.
|
|
|
|
|
|
Make fz_clone_context copy existing AA settings.
Add accessor function for fz_bitmap.
Add more documentation for various functions/types.
|
|
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.
|
