Specifically,
cairo_region_union_rect -> cairo_region_union_rectangle
cairo_region_create_rect -> cairo_region_create_rectangle
Also delete cairo_region_clear() which is not that useful.
Usually, rectangles are more useful than boxes, so regions should only
expose rectangles in their public API.
Specifically,
_cairo_region_num_boxes becomes _cairo_region_num_rectangles
_cairo_region_get_box becomes _cairo_region_get_rectangle
Remove the cairo_box_int_t type
The _cairo_region_get_boxes() interface was difficult to use and often
caused unnecessary memory allocation. With _cairo_region_get_box() it
is possible to access the boxes of a region without allocating a big
temporary array.
Adds an error code replacing CAIRO_STATUS_NO_MEMORY in one case where it
is not really appropriate. CAIRO_STATUS_INVALID_SIZE is used by several
backends that do not support image sizes beyond 2^15 pixels on each side.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If we are dithering on the Xlib backend we can not simply repaint the
surface used for a solid pattern and must recreate it from scratch.
However, for ordinary XRender usage we do not want to have to pay that
price - so query the backend to see if we can reuse the surface.
A surface will have the chance to use span rendering at cairo_fill()
time by creating a renderer for a specific combination of
pattern/dst/op before the path is scan converted. The protocol is to
first call check_span_renderer() to see if the surface wants to render
with spans and then later call create_span_renderer() to create the
renderer for real once the extents of the path are known.
No backends have an implementation yet.
Allow the user to pass in a pre-allocated array and use it if the number
of boxes permits. This eliminates the frequent allocations during clipping
by toolkits.
Ginn Chen reported a regression with Firefox where "the whole area of web
page is transparent until it redraws", and bisected it to the change to
lazily clear the clip.
The bug would appears to be when we have an inconsistent GC clip - i.e.
the clip on the surface has been cleared, but we have not yet used and
thus cleared the GC, so that we did not mark the GC as having a clip set
when we freed it.
Add a "cairo_rectangle_int_t *extents" argument to to the following
backend functions:
paint
mask,
stroke
fill
show_glyphs
show_text_glyphs
This will be used to pass the extents of each operation computed by
the analysis surface to the backend. This is required for implementing
EXTEND_PAD.
libXrender amalgamates sequences of XRenderFillRectangle() into a single
XRenderFillRectangles request (when permissible). Since it is common for a
cairo application to draw rectangles individually in order to exploit fast
paths within cairo [rectilinear fills], it is a reasonably common pattern.
Constructing the font options cause the initialisation of Xlc and invoke
several round-trips to the X server, significantly delaying the creation
of the first surface. By deferring that operation until the first use of
fonts then we avoid that overhead for very simple applications (like the
test suite) and should improve start-up latency for larger application.
Only copy the pattern if we need to modify it, e.g. preserve a copy in a
snapshot or a soft-mask, or to modify the matrix. Otherwise we can
continue to use the original pattern and mark it as const in order to
generate compiler warnings if we do attempt to write to it.
Adrian Johnson discovered cases where we mistakenly compared the result
of unsigned arithmetic where we need signed quantities. Look for similar
cases in the users of cairo_rectangle_int_t.
If the image was opaque with no alpha channel, we filled the output alpha
with 0. Typically, the destination surface for dithering is an RGB window,
so this bug went unnoticed. However, test/xlib-expose-event is an example
where we generate an intermediate alpha-only pixmap for use as a stencil
and this was failing as the mask was left completely transparent. The
simple solution is to ensure that for opaque images, the output alpha is
set to the maximum permissible value.
After discussing the scaled font locking with Behdad, it transpired that it
is not sufficient for a font to be locked for the lifetime of a scaled glyph,
but that the scaled font's glyph cache must be frozen for the glyph'
lifetime. If the cache is not frozen, then there is a possibility that the
glyph may be evicted before the reference goes out of scope i.e. the glyph
becomes invalid whilst we are trying to use it.
Since the freezing of the cache is the stronger barrier, we remove the
locking/unlocking of the mutex from the backends and instead move the
mutex acquisition into the freeze/thaw routines. Then update the rule on
acquiring glyphs to enforce that the cache is frozen and review the usage
of freeze/thaw by all the backends to ensure that the cache is frozen for
the lifetime of the glyph.
Bug 9102 cairo doesn't support 24 bits per pixel mode on X11
(https://bugs.freedesktop.org/show_bug.cgi?id=9102)
is a reminder that that we need to support many obscure XImage formats.
With Carl's and Behdad's work to support psuedocolor we have a mechanism
in place to handle any format that is not natively handled by pixman. The
only piece we were missing was extending the swapper to handle all-known
formats and putting in defensive checks that pixels were correctly aligned
in accordance with pixman's requirements.
Bug 11734:
XRender crashes due to NULL pointer from Cairo on SGI O2
(https://bugs.freedesktop.org/show_bug.cgi?id=1173)
is an example of a case where we try to perform an XRender operation on a
surface with a format that was not supported by the XRender extension. By
marking the extension version as -1 on those surfaces, the current checks
for SURFACE_RENDER_HAS_* always correctly return false and prevent us try
to create a Picture with a NULL xrender_format.
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).
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.
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.
_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.
A little bit of sleep and reflection suggested that the use of
device_offset_[xy] was confusing and clone_offset_[xy] more consistent
with the function naming.
Previously the rule for clone_similar() was that the returned surface
had exactly the same size as the original, but only the contents within
the region of interest needed to be copied. This caused failures for very
large images in the xlib-backend (see test/large-source).
The obvious solution to allow cloning only the region of interest seemed
to be to simply set the device offset on the cloned surface. However, this
fails as a) nothing respects the device offset on the surface at that
layer in the compositing stack and b) possibly returning references to the
original source surface provides further confusion by mixing in another
source of device offset.
The second method was to add extra out parameters so that the
device offset could be returned separately and, for example, mixed into
the pattern matrix. Not as elegant, a couple of extra warts to the
interface, but it works - one less XFAIL...
The adjustments done to the pixman matrix also need to be done for
XTransform. Since an XTransform is just a pixman_transform_t with
another name, we can reuse the conversion function.
Cleanup the code somewhat by passing cairo_xlib_display_t around
internally as opposed to a Display and then having to lookup the
corresponding cairo_xlib_display_t each time.
[To get a cairo_xlib_display_t from a Display is a list traversal under
mutex (though the element we're looking for is most likely at the start),
but to get the Display is just a lockless pointer dereference.]
