If the clip wholly covers the operation, we do not need to set one, and
if the current clip similarly covers the operation we do not to unset
it.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If the surface already has a clip set and that clip does not interfere
with the operation then we can leave it set.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If the extents of the operation is wholly contained within the clip
region, then we can safely not invoke any clipping.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
We need to special case the handling of unaligned clip regions in order
to prevent the treatment of those as a general path requiring a
clip+mask...
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
A mesh pattern is put in CAIRO_STATUS_INVALID_MESH_CONSTRUCTION when
an invalid patch construction operation is performed.
A mesh pattern is put in CAIRO_STATUS_INVALID_INDEX when an operation
is performed with an out-of-bound index.
Any pattern is put in CAIRO_STATUS_INVALID_MATRIX when its matrix is
set to a singular matrix.
In order to have a behavior which is coherent with that of surfaces,
flushing a finished devices should be a no-op and should not affect
the status of the device.
The replay of the recording surface will not function correctly unless
the target surface region is already clear. So assume that is and
optimise away the initial clear.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Clang static analysis relies on the Core Foundation naming convention
for the object ownership tracking.
Functions that return an object whose ownership is given to the
caller, should contain "Create" or "Copy" in their name.
The code incorrectly initialized the fields of the data structure,
which are about to be overwritten, instead of the temporary variables
which are used to compute them.
This turns the test suite-failures for map-all-to-image map-bit-to-image
map-to-image-fill with xcb-fallback into failed assertions.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Recording surfaces can be unbounded which causes
_cairo_surface_acquire_source_image to return a 0x0 image surface for them.
Since X11 doesn't like anything with a size of 0x0, we should reject such source
images. Users might still try to mess with 0x0 surfaces, so we will eventually
need a better idea for handling this.
Instead of failing the assertion that was added in the previous commit, this
commit makes cairo-xcb return an error.
This makes the recording-* tests fail instead of crash.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Currently, all the recording-* tests fail with an X11 error. This commit turns
those errors into failed assertions. Now someone just has to figure out why this
happens in the first place...
Signed-off-by: Uli Schlachter <psychon@znc.in>
As a recording surface will be replayed onto a destination target, it is
unknown at the time of creation as to whether or not the target is
clear. So we need to make sure to record any initial clear in order
to replay that clear onto the destination. (If the destination is clear
anyway it will be suppressed.)
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The edge clipper is more complicated than it should be and contains a
subtle bug: when an edge is almost horizontal, it is always considered
as having a positive slope.
Explain what should be done and do it in a simpler way.
Fixes horizontal-clip.
When we don't generate the set of visible indices, we need to iterate
over all the currently active commands and so need to offset the
iterator to the start of those commands.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
By using a bounding-box rtree, we are able to reject invisible branches
of the tree and so find the visible leafs with fewer intersection
checks. Overhead reduction is strongly dependent upon the ability to
spatially partition the geometry and so performance correlates with
small tiles and small operations.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This function never fails. However, since it's used to implement a operation for
cairo_surface_backend_t, the return value can't be void. This commit instead
uses cairo_private_no_warn to get rid of the warnings.
Signed-off-by: Uli Schlachter <psychon@znc.in>
The previous commit fixed a bug in cairo-xlib found by a similar assert, so this
seems to be a good idea to have.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Uli Schlachter analysed the error behind the polygon reduction and
discovered that it was due to the clipping of a line which intersects
the clip box (p1, p2) but is range limited by (top, bottom) to be inside
the clip box.
Fixes hatching
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As Andrea Canciani pointed out even if it is horizontal within the clip
box, it may still have vertical extents outside of the clip box for
which we need to project onto the clip boundary in order to maintain
the correct polygon winding.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
A stepping stone, the translation was accidentally dropped when
changing the clipping to be performed first.
Fixes twin.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
For an unbounded surface we cannot assume (0, 0, surface_width,
surface_height) as that is wrong and causes the operation to appear
clipped.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
A common requirement is the fast upload of pixel data. In order to
allocate the most appropriate image buffer, we need knowledge of the
destination. The most obvious example is that we could use a
shared-memory region for the image to avoid the transfer cost of
uploading the pixels to the X server. Similarly, gl, win32, quartz...
The other side of the equation is that for manual modification of a
remote surface, it would be more efficient if we can create a similar
image to reduce the transfer costs. This strategy is already followed
for the destination fallbacks and this merely exposes the same
capability for the application fallbacks.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Gah, I thought about this and noted that I need the inverse of the
normal transformation, yet failed to remember to actually use it.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
