The only reliable method would be to query the xserver for the
matching bpp for a particular depth. In the absence of such information,
simply chose the next higher power-of-two(depth).
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Both MSVC and Sun Studio Compiler complain about void values being
returned.
Fixes:
cairo-raster-source-pattern.c(93) : warning C4098:
'_cairo_raster_source_pattern_release' : 'void' function returning a
value
CAIRO_ANTIALIAS_{FAST,GOOD,BEST} were introduced and used in
cairo-quartz-font.c by commit 70cd3b473d.
Fixes the warnings:
cairo-quartz-surface.c: In function '_cairo_quartz_cg_glyphs':
cairo-quartz-surface.c:1976: warning: enumeration value 'CAIRO_ANTIALIAS_FAST' not handled in switch
cairo-quartz-surface.c:1976: warning: enumeration value 'CAIRO_ANTIALIAS_GOOD' not handled in switch
cairo-quartz-surface.c:1976: warning: enumeration value 'CAIRO_ANTIALIAS_BEST' not handled in switch
Just create a image wrapper for a 0x0 surface, and do not try to create
an image surface that is larger than the maximum X coordinate.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Currently we perform the conversion using XPutPixel which is hideously
slow and so it is faster to create a new surface that matches the
format correctly, upload and allow X to perform the conversion. In other
words disable the "fast" path for format mismatches.
Based on a patch by Ginn Chen <ginn.chen@oracle.com>
Bugzilla: https://bugzilla.mozilla.org/show_bug.cgi?id=716462
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
On deleting an EGL device, it is possible that
cairo_egl_context_t::dummy_surface is EGL_NO_SURFACE. In that case
calling eglDestroySurface() on it will lead to EGL_BAD_SURFACE error.
Check dummy_surface before destroying it.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Instead of using the stencil buffer to perform simple
rectangular clips, just scissor the clip rectangle.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
[ickle: fixed application to master]
If the clip suggests anti-aliasing and we don't support it,
draw the clip anyway. Currently disabling anti-aliasing does
not disable anti-aliasing on certain clips.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If the clip failed, not resetting the color mask leaves the GL context
in a state in which we cannot draw anything.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
One of the remaining issues with msaa is Cairo's insistence on
allocating a depth-stencil for every target. These cause massive
overallocation and prevents my machines from completing
cairo-perf-trace. So for the time being switch back to the old
fashioned span-based compositor.
To continue development of msaa, or indeed other compositors, we
introduce the CAIRO_GL_COMPOSITOR env variable to allow the default
compositor to be selected. Use CAIRO_GL_COMPOSITOR=msaa to continue to
use the msaa compositor for instance.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
EGL mandates that the current context be valid for a call to
swapbuffers, and does not just operate upon the drawable passed in. The
current code prevents this as a side effect of calling flush decouples
the current context (so that the state can be clobbered by the
application without impacting upon Cairo). So when we try to swap, EGL
complains.
We can get the desired behaviour by setting the surface upon the
context, thus calling MakeCurrent as necessary, and then flushing any
pending operations before swapping. This has the positive side-effect
of not clobbering our own state unnecessarily.
Reported-by: Pekka Paalanen <ppaalanen@gmail.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
An unbounded recording surface will complain loudly when you call
acquire_source_image on it and thus we need a special case which draws the
recording surface to a temporary surface and then proceeds with that.
Signed-off-by: Uli Schlachter <psychon@znc.in>
userdict is not permitted in EPS files. Since the PS surface does not
leave extra operators or dictionaries on the stack the EPS prolog and
trailer can be reduced to:
save
50 dict begin
....
end
restore
The save/restore pair is required to remove fonts and restore the
graphics state. As "restore" does not restore the dictionary stack,
using a new current dictionary for the EPS file allows the cairo dict
entries to be cleaned up at the end the EPS.
Bug 43634
In the case where we created a surface to handle an operand, it needs to
be freed when we release the operand. However, we also have to be
careful not to introduce reference cycles into ordinary surfaces, so
always remember to teardown the composite setup!
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The operand->texture.surface should be set to right value, not
NULL. Otherwise, when doing _cairo_gl_surface_operand_init(),
the texture.surface in operand struct will also be NULL, which
is incorrect. This fix regression suite in 43 test cases(such
as source-clip) in cairo/test/.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This was introduced in a69335a84e when the second argument of
_cairo_xcb_surface_create_similar_image was changed from content to format.
Signed-off-by: Uli Schlachter <psychon@znc.in>
In order to decouple the texture node from the scaled glyph cache, we
need to add a callback from the rtree for when the node is removed.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Allocating a stencil and a depth buffer for every destination surface is
simply too expensive and causes major resource issues. So defer the
allocation and attachment of a stencil buffer until just prior to first
use.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
None of the cairo clipping computations guarantee that the resulting
list of rectangles are constructed in any particular order. Promising
that they are results in an X error (BadMatch) which generally causes
applications to crash.
I suspect this may well be implicated in many (many) bug reports about
applications which use cairo.
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As we evaluate the line first using y-for-x to find the clipped
vertical range and then rasterise the line using x-for-y, we can incur
severe rounding errors that cause us to draw beyond the clipped region.
The first simple attempt at a fix is to tweak the clipped vertical range
such that the evaluated extents of the line are contained.
Reported-by: Taekyun Kim <tkq.kim@samsung.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
