Caching is fragile sinle the enable commands cannot have any side-effects
when caching. And doesn't have significant speedup at this level. Just
remove it.
Compiler warning saves the day!
trace.c: In function ‘_emit_font_options’:
trace.c:2973:20: warning: comparison between ‘cairo_hint_style_t’ and
‘enum _cairo_hint_metrics’
A genuine bug, thanks gcc!
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
cairo_set_font_size() should be equivalent to setting the font matrix
to an appropriate scale matrix.
Implementing it this way saves some code and makes sure that the same
code path is used whenever the font matrix is changed.
3-sided boxes can be replaced with rectangles when clipping and
filling, but not when stroking. _emit_path() is used for all of these
operations, so it cannot perform the optimization except for 4-sided
boxes.
Fixes stroke-open-box.
__cairo_path_fixed_is_rectangle() is used by the PS and PDF backends
to check if a path is equivalent to a rectangle when stroking. This is
different from being a rectangle when filling, because of the implicit
close_path appended to every subpath when filling.
Fixes stroke-open-box.
See https://bugs.freedesktop.org/show_bug.cgi?id=34560
The RENDER specification requires radial gradients to have the first
circle completely inside the second one, but the error is not actually
generated.
The implementation produces the expected results if either circle
contains the other one, so only fall back in these cases.
The RENDER specification does not specify the constraints on the
gradient stops, but its implementation returns an error if less than 2
stops are used.
Xlib and XCB can work around this because gradients with just one stop
are by-definition the same as gradients with that stop repeated twice.
Fixes radial-gradient-one-stop.
This new test (based on show-glyphs-many) checks that the glyphs
advances are respected along both axes.
9c0d761bfc introduced a bug which
regresses this test in quartz.
Thanks to Jeff Muizelaar for the report!
The ARRAY_LENGTH macro is used by many tests, although sometimes it is
named ARRAY_SIZE. Define it just once in cairo-test.h and reuse it.
In a similar way, MAX() and MIN() are currently defined in some
specific tests, while they could be reused.
warning: cannot optimize possibly infinite loops
gcc does not detect that the "infinite" loops are actually just one or
two iterations, depending on the has_similar value being FALSE or
TRUE. It realizes it if the iteration variable and the iteration stop
value are both enum values.
cairo-trace already depended upon HAVE_FUNLOCKFILE for its
thread-safety.
[This is a candidate for 1.10.]
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
All cairo_xcb_picture_t now get their own, private Picture instead of possibly
sharing it with a cairo_xcb_surface_t.
This solves a cyclic dependency which caused cairo_xcb_picture_t to be leaked
until their device was finished.
When an xcb surface was used as a source, a cairo_xcb_picture_t was created
which kept a reference to the surface. This picture was then added as a snapshot
to the surface which caused the surface to own a reference to the picture.
As a result, the Picture and possibly its associated Pixmap were not freed on
the X11 server which could thus run out of memory.
This change causes more Pictures to be created which could possibly slow down
cairo-xcb. There seems to be no measurable difference with cairo-perf-trace. For
the micro benchmarks, this has the most impact on paint_similar-rgba_source.512:
min(ticks) min(ms) median(ms) stddev. iterations overhead
before 158732 0.159 0.159 0.11% 4: 1651.49
after 162579 0.163 0.163 0.18% 4: 1612.41
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=34912
Signed-off-by: Uli Schlachter <psychon@znc.in>
When running cairo-test-suite with "-a", backends are also tested with a
non-zero device offset. However, for "xcb-window&" the boilerplate incorrectly
overwrote the device offset with a zero offset again.
This caused all test results to be offset by 25 pixels which obviously makes all
tests fail.
Just removing the call to cairo_surface_set_device_offset solves the problem.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This flag was only ever tested, but never set. Also, there is no X11 server out
there which actually supports this.
AFAIK it was just an experiment which turned into dead code.
Signed-off-by: Uli Schlachter <psychon@znc.in>
RENDER 0.11 added PDF operators and the cairo-xcb backend is already prepared
for handling them. However, it doesn't actually handle them.
If you used such an operator with RENDER 0.11, _operator_is_supported() would
return TRUE, but later on an ASSERT_NOT_REACHED in _render_operator() is hit.
Signed-off-by: Uli Schlachter <psychon@znc.in>
All of these defines where not used anymore and this '#if 0'd code was so for
ages and most likely would stay commented out for more ages, too.
Signed-off-by: Uli Schlachter <psychon@znc.in>
We never bound any other value to the sampler uniforms, so why bother
resetting them all the time?
[ 0] before firefox-talos-gfx 29.972 30.493 0.89% 3/3
[ 0] after firefox-talos-gfx 29.397 29.599 1.27% 3/3
Signed-off-by: Eric Anholt <eric@anholt.net>
Because of GLX's unfortunate requirement that only one context have a
thread current at a time, we had to unbind the context, triggering a
flush, and eating of all the CPU. With a small tweak to the GLX spec
by GLX_MESA_multithread_makecurrent, and a small tweak to Mesa that
consisted mostly of deleting the "is this thread already bound
elsewhere?" check, we can bind our context to any thread and use it
safely as long as our usage of it is mutexed, which cairo-gl should
already be doing.
[ 0] before firefox-talos-gfx 50.260 50.525 0.25% 3/3
[ 0] after firefox-talos-gfx 32.091 32.422 0.65% 3/3
Since its inception, cairo-gl has been plagued by the "how am I really
supposed to use it?" problem. This lays down my expectations for how
cairo-gl will interact with other usage of the GL API.
If PIXMAN_HAS_ATOMIC_OPS, ix and iy will be changed if the source
surface is of subsurface type. They need to be reset to 0 before being
passed to _cairo_matrix_to_pixman_matrix_offset() or the acquired
surface will have an incorrect offset .
The pixman_image_ref() and pixman_image_unref() functions
aren't threadsafe in current pixman, so we can't share
pixman images across contexts where they may end up
moving between threads. The main use of these functions
is in keeping a global cache of pixman_image_ts for
solid colours and reusing the same pixman_image_t for
patterns pointing to the same image data where possible.
This patch removes those uses from cairo by wrapping
them in a PIXMAN_HAS_ATOMIC_OPS conditional. There is
no automatic test this, so we will have to manually
turn this code back on when pixman does gain atomic
ops.
The only two remaining calls to pixman_image_ref() are
done on locally created images so they are safe.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=34177
