A precondition for using the core XCopyArea protocol is that the source
attributes contain only integer translations. However, we failed to apply
any integer translations from the source matrix to the XCopyArea offsets.
This worked prior to 5b97ee6525 as
_cairo_pattern_acquire_surface_for_surface() was careful to only generate
an identity matrix if the pattern matrix only contained an integer
translation (and thus we would use XCopyArea in the xlib backend).
gtk-doc fails make check for array as it insists that even the simplest
functions must have a long description and cannot be entirely described by
their arguments and return value.
During insertion we must traverse the skiplist in order to find the
insertion point for the new element. As we descend each level, the next
element in the chain for this level is sometimes the same as the one we
just compared against (and know that the new element is greater than).
Hence we can skip the search on that level and descend to the next. During
world_map this reduces the number of calls into _sweep_line_elt_compare()
by ~2.5% (and when performing trapezoidation on strokes gives a similar
speed up of about 2% - not bad for the addition of a single line.)
Use primitives from cairo-wideint-private.h - in this case it helps to
make the code more readable as well as reduce dependence on native 64bit
integers.
Prefer to use the operations form cairo-wideint-private.h in order to
improve readability and reduce our assumptions on the availability of
64bit integers.
'const' is a stricter form of 'pure' in that functions declared with that
attribute do not access any values other than their arguments (in
contrast to 'pure' which is allowed to read from global memory).
Take advantage of the gcc function attribute 'pure', which tells gcc that
the function result only depends upon its arguments and it has zero side
effects (e.g. it does not clobber memory). This gives gcc greater
opportunity to rearrange and optimize the wideint arithmetic.
We often use the construct:
if (_cairo_int64_lt (A, B)
return -1;
if (_cairo_int64_gt (A, B)
return 1;
return 0;
to compare two large integers (int64, or int128) which does twice the
required work on CPUs without large integer support. So replace it with a
single wideint function _cairo_int64_cmp() and therefore allow
opportunities to both shrink the code size and write a more efficient
comparison. (The primarily motivation is to simply replace each block with
a single more expressive line.)
If the sweep-line is currently on an end-point of a line,
then we know its precise x value and can use a cheaper comparator.
Considering that we often need to compare events at end-points (for
instance on a start event), this happens frequently enough to warrant
special casing.
We need to compare the x-coordinate of a line at a for a particular y,
without loss of precision.
The x-coordinate along an edge for a given y is:
X = A_x + (Y - A_y) * A_dx / A_dy
So the inequality we wish to test is:
A_x + (Y - A_y) * A_dx / A_dy -?- B_x + (Y - B_y) * B_dx / B_dy,
where -?- is our inequality operator.
By construction we know that A_dy and B_dy (and (Y - A_y), (Y - B_y)) are
all positive, so we can rearrange it thus without causing a sign
change:
A_dy * B_dy * (A_x - B_x) -?- (Y - B_y) * B_dx * A_dy
- (Y - A_y) * A_dx * B_dy
Given the assumption that all the deltas fit within 32 bits, we can compute
this comparison directly using 128 bit arithmetic.
The convex_quad tessellator (and possibly even the more general polygon
tessellator) will generate empty trapezoids when given a
rectangle which can be trivially discarded before inserting into traps.
Move the predicate for starting a new glyph elt into a macro so that it
can be shared between _cairo_xlib_surface_emit_glyphs() and
_emit_glyph_chunks() without code duplication.
_cairo_xcb_surface_is_similar() is currently only used by the pattern
cache to determine whether to keep the surface in the solid color cache.
This is fundamentally broken without hooking into Display closure as it
keeps a reference to an expired picture. So in order to prevent spurious
application crashes, disable the caching for xcb.
As reported by Damian Frank:
"I ran into a hitch with the Makefile.win32 infrastructure. It uses -MD and
-LD when linking regardless of the config, but it should be using -MDd and
-LDd for the debug config. I believe both the Makefile.win32.common and
src/Makefile.win32 files include erroneous declarations. This produces
warnings at link time about a mismatch when linking against properly created
debug libs (for instance, I had a zlib built as "LIB ASM Debug" that linked
properly against the debug runtime).
This problem applies to pixman too; can you pass this along to the
maintainer?"
Would be delighted to if someone commits a fix to pixman reading this
commit message.
This reverts commit 0eb0c26474.
The change was too drastic and overlooked some subleties of the old
code, but the main reason for the revert is that it introduced an
ugly duplicated glyph flush block. I'm working on a more incremental
fix.
show-glyphs-many is triggering an assertion failure within xlib. The cause
appears to be that we are submitting an overlong request.
Reviewing the code and comparing with libXrender/src/Glyph.c I found two
points to address.
1. When encountering the first 2-byte, or 4-byte glyph and thus triggering
the recalculation of the current request_size, we did not check that there
was enough room for the expanded request. In case there is not, we need to
emit the current request (before expansion) and reset.
2. Subtleties in how XRenderCompositeText* constructs the binary protocol
buffer require that xGlyphElts are aligned to 32-bit boundaries and that
it inserts an additional xGlyphElt every 252 glyphs when width==1 or
every 254 glyphs for width==2 || width==4. Thus we need to explicitly
compute how many bytes would be required to add this glyph in accordance
with the above.
Considering the complexity (and apparent fragility since we require tight
coupling to XRender) of the code, I'm sure there are more bugs to be
found.
In the midst of porting 5eec3e378a I failed
to include the pad in the floor() and ceil() which introduces two
potential off-by-one errors into each dimension of the region of interest
of the source surface.
Resolve the seemingly conflicting two paragraphs that instruct the writer
of a user-font on when to allocate the glyphs array during text_to_glyphs,
so that it is consistent with itself and the code. In particular, I could
find no indication in the code that num_glyphs is preset to -1 (it should
be a user parameter reflecting the number of entries in the supplied glyph
buffer) and the callback must allocate the array using
cairo_glyph_allocate().
Factor out common filter analysis code from _cairo_pattern_get_extents()
so that we can share it with _cairo_pattern_acquire_surface_for_surface()
as well. During the analysis of the filter determine whether the pattern
matrix maps source pixels exactly onto destination pixels and if so convert
the filter to NEAREST - generalising the existing conversion to NEAREST.
(Patch ported to master by Chris Wilson, all bugs are his.)
This fixes the filter-bilinear-extents test case and the
related bug entry:
bad clipping with EXTEND_NONE
http://bugs.freedesktop.org/show_bug.cgi?id=15349
Though there are still differences in the PDF and PostScript
backends, (primarily because we can't capture cairo's filter
modes in those file formats).
Restrict the area we acquire from the source image to the bounds of
the source image, even when we have an identity matrix. This handles
circumstances where the pattern extents may be enlarged due to
filtering, for example when applying a bilinear filter.
This patch replaces the open-coded rectangle intersection which has
already proven itself to be a source of bugs.
(Patch ported to master by Chris Wilson, all bugs are his.)
Remove instances (abuses) of calling _cairo_pattern_acquire_surface() on
a known-surface-pattern with a hack to say "give me the entire surface".
If you know you just want the entire surface as an image surface, that
can be done more simply.
(Split from original patch on
https://bugs.freedesktop.org/attachment.cgi?id=15703, by Chris Wilson -
as usual all bugs are his.)
I wonder whether merely fixing a compile error in glitz will do anything
towards its utility... Anyway fix the missing comma as reported by
Shunichi Fuji and correct the asserts.
_surfaces_compatible in cairo-xlib-surface returns true for surfaces with
different xrender_format when each has the same depth and no (NULL)
visual.
Common picture formats will not have the same depth, but
it is possible to create a surface with a non-standard xrender_format
having the same depth as another xrender_format with
cairo_xlib_surface_create_with_xrender_format.
Both cairo_xlib_surface_create_with_xrender_format and
_cairo_xlib_surface_create_similar_with_format create surfaces with no
visual.
The same issue exists in the xcb backend.
Fixes bug https://bugs.freedesktop.org/show_bug.cgi?id=16564.
Previously, the SVG backend would rash when new operators were added to
cairo.h, now it returns UNSUPPORTED.
Also unsupported operators can now be set as NULL, so image fallbacks can
be used properly.
Should use fallbacks instead of color-dodge for CAIRO_OPERATOR_STURATE?
Because we can independently set either the device scale or the device
offset, we need to be careful and recompute the inverse rather than simply
assuming that the original contents of the device transform is identity.
Fixes regression https://bugs.launchpad.net/inkscape/+bug/234546.
