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).
mitch reported on irc that expose events in the gimp were suffering from
artifacts which he tracked down to a bug with clipping and source
surfaces. This is the cairo test case for that regression.
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).
In the cairo 1.8.0 release the documentation would get generated with
the second and third version components transposed, (so it would say
1.0.8). Fix the obviously mistaken transposition.
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.)
There appears to be no simple solution here, as it seems to be a
fundamental flaw in the design of the meta-surface wrt to replaying into
a fallback image. (I may be wrong, but if Carl found no easy solution then
I feel no shame for my own failure ;-)
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.
These are the versions available on RHEL5 (two years old now), and
we know cairo works with them. There's evidence that our build system
does not work with older automake, and we've been requiring autoconf 2.58
but no one ever tested 2.58 with the new build system. It's very likely
that 2.58 doesn't work and needs some macro backporting. In any case,
no one reported that they have 2.58 when I asked on the list.
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.
Within _cairo_xlib_surface_emit_glyphs() there are a number of
complications to do with packing as many glyphs as possible into a
single XRenderCompositeGlyph*() call. Essentially these consist of
choosing the right function and packing for the current glyphs, describing
runs of glyphs and ensuring that we do not exceed the maximum request size
within a single call. So we add to the test case we an attempt to show 64k
2-byte glyphs and an attempt to mix 64k 1-byte and 2-byte glyphs, with the
change-over point chosen to overflow the maximum request size, should
_cairo_xlib_surface_emit_glyphs() naively resize the current request.
Moral of this story is bugs cluster. If we made a mistake, especially in a
complicated bit of code that is interfacing with another library, then we
are likely to make a similar mistake in future. Disabling this test hid a
regression between 1.4 and 1.6.
I swear that when I said that it was a rounding error, I was looking at an
image where the squares were overlapping the lines and had a listing of
all the coordinates used. However, the current output on all the machines
I have to hand is correct so I believe the underlying bug to be fixed.
Update the reference images for the external renderers because (a) GS
exhibits the same bug cairo had and (b) librvsg/PDF do not use NEAREST
when applying surface patterns, so the squares are blurred as a result.
Avoid requiring (an absent!) rgb24 ref image by using an opaque grey
background. Confirm the reference image is identical to the old one
(modulo the background change) using GIMP.
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.
Sigh - finding a crasher in xlib seemed too good to be true. And it was.
The bug is due to the coupling of the XCloseDisplay with the user_data on
the source surface.
This was an externally trigger XCloseDisplay whilst the user had live
surfaces, so I consider this a gross application bug and therefore does
not require graceful handling within cairo-xlib. However, I'm willing to
listen to reason...
