2fb4a0e119 made the
_cairo_surface_subsurface_set_snapshot available with default
visibility.
'make check' correctly points out that it should be marked as private.
If the sample is wholly contained within the subsurface of the original,
we can simply use the original with an offset; thereby only copying the
data if we are sampling outside the subsurface bounds.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
In order to handle reference cycles during finish (through snapshots) we
need to bump the reference on the surface first.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Following the previous commit, we only allocate a simple image when
acquiring the source so we only need to unreference it upon release.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Remove all of the special casing and simply extract the source. The time
for special casing is to avoid calling the generic acquire in the first
place, so kiss.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
In order to handle out-of-bounds sampling of a subsurface target we need
to first avoid incorrectly unwrapping it.
Fixes crash in subsurface-outside-target
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
In order to keep the bookkeeping in order, and so prevent a later
assert, we need to clear any edges when swapping the active edge order
upon an intersection event. The active edges are then reconstructed.
Fixes evince http://www.horizonhobby.com/pdf/BLH3500-Manual_EN.pdf
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Avoid the assertion failure of creating an error surface for an internal
status by handling the expected UNSUPPORTED condition.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The test failed with the following message:
cairo-surface.c:2265: _cairo_surface_create_in_error: Assertion `status <
CAIRO_STATUS_LAST_STATUS' failed.
_cairo_xcb_surface_create_shm_image() passed the error from
_cairo_xcb_connection_allocate_shm_info() to _create_in_error().
Fix this by never returning CAIRO_INT_STATUS_UNSUPPORTED from
_allocate_shm_info(). All other error cases in that function return
CAIRO_STATUS_NO_MEMORY, too.
Signed-off-by: Uli Schlachter <psychon@znc.in>
cairo-xcb was deciding which type to cast a surface to based on its "type"
member. This is wrong, it should use "backend->type".
This bug was hit via xlib-xcb. This was painting a subsurface of a xlib-xcb
surface to an xcb surface. Because surface->type said "xlib", the code was
trying to check if the xcb surface had a fallback. However, this was done on the
subsurface. The end result was dereferencing a pointer to 0x28.
This was noticed while looking into
https://bugs.freedesktop.org/show_bug.cgi?id=42889
No test for this bug since I didn't manage to come up with one.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This patch has been generated by the following Coccinelle semantic patch:
// Remove useless checks for NULL before freeing
//
// free (NULL) is a no-op, so there is no need to avoid it
@@
expression E;
@@
+ free (E);
+ E = NULL;
- if (unlikely (E != NULL)) {
- free(E);
(
- E = NULL;
|
- E = 0;
)
...
- }
@@
expression E;
@@
+ free (E);
- if (unlikely (E != NULL)) {
- free (E);
- }
The xml backend structure was being initialized with the wrong
functions, resulting in multiple "initialization from incompatible
pointer type" warnings.
'make check' reports:
Checking that .libs/libcairo.so has the same symbol list as cairo.def
1a2,3
> _cairo_default_context_fini
> _cairo_default_context_init
Checking .libs/libcairo.so for local PLT entries
0011a274 00025f07 R_386_JUMP_SLOT 00026350 _cairo_default_context_fini
0011a494 00027607 R_386_JUMP_SLOT 00026480 _cairo_default_context_init
Marking these functions as cairo_private fixes the problem.
'make check' reports:
./cairo-cogl-context.c: * cairo_path_fixed_t in user coordinates that we can use to create a
./cairo-cogl-context.c: * We use this hash to lookup a cairo_cogl_path_meta_t struct which
./cairo-cogl-context.c: * need to use the cairo_path_fixed_t api to describe a rectangle in terms of
./cairo-cogl-context.c: * passed the current cairo_t context we don't have a good way
Error: some type names in the docs are not prefixed by hash sign,
neither are the only token in the doc line followed by colon.
Fix this by searching for the following regexp in the above files:
'^[^:]*:[/ ][*]\( .*[^#']\| \|^\)\<cairo[0-9a-z_]*_t\>\($\|[^:]$\|[^:].\)'
./cairo-cogl-context.c: * cairo_path_fixed_t in user coordinates that we can use to create a
./cairo-cogl-context.c: * We use this hash to lookup a cairo_cogl_path_meta_t struct which
./cairo-cogl-context.c: * need to use the cairo_path_fixed_t api to describe a rectangle in terms of
./cairo-cogl-context.c: * passed the current cairo_t context we don't have a good way
Error: some function names in the docs are not followed by parentheses.
Fix this by searching for the following regexp in the above files:
'^[^:]*:[/ ][*]\(\|[ ].*\)\([^#']\|^\)\<\(cairo_[][<>/0-9a-z_]*\>[^][<>(]\)'
Checking that source files #include "cairoint.h" first (or none)
cairo-cogl-context.c:#include "cairo-cogl-context-private.h"
These are fixed trivially by this patch.
Add the missing includes, fix a typo and some changes in the
signatures of the backend functions.
The dest acquisition functions can be removed as they are not used
anymore in the new compositor architecture (this will probably cause
failures when fallbacks are tried because of unsupported operations).
In 545f3085.. the cairo_spline_add_point_func_t type was modified to
accept the tangent in the point, but cairo-rectangle.c was not updated
accordingly.
Fixes:
cairo-rectangle.c: In function '_cairo_box_add_curve_to':
cairo-rectangle.c:297:11: warning: passing argument 1 of
'_cairo_spline_bound' from incompatible pointer type
Add support for basic solid color strokes using the fixed path
stroke shaper. Currently components of the stroke overlap, but
that will be handled in the following patch.
Adds basic clipping to the OpenGL MSAA compositor via the
depth and stencil buffers. Stenciling and depth bits are
stored in a renderbuffer.
Note that we only attach renderbuffers to surfaces created by ourselves
and not for foreign drawables (e.g. X Windows).
Reported-by: Ingo Ruhnke <grumbel@gmx.de>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=40456
Original-patch-by: Simon Elmir <nerd65536+freedesktop@gmail.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Trimming the composite extents may result in the clip being
reconstructed, but we the polygon continued to hold a reference into the
freed clip's array of boxes. So if we intend to reuse the polygon limits
after performing the clip we need to refresh them.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
