Having spent the last dev cycle looking at how we could specialize the
compositors for various backends, we once again look for the
commonalities in order to reduce the duplication. In part this is
motivated by the idea that spans is a good interface for both the
existent GL backend and pixman, and so they deserve a dedicated
compositor. xcb/xlib target an identical rendering system and so they
should be using the same compositor, and it should be possible to run
that same compositor locally against pixman to generate reference tests.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
P.S. This brings massive upheaval (read breakage) I've tried delaying in
order to fix as many things as possible but now this one patch does far,
far, far too much. Apologies in advance for breaking your favourite
backend, but trust me in that the end result will be much better. :)
As handling joins/caps between line segments shorter than
half_line_width is tricky.
Rather than also fixing the bug in traps, remove that code. The plan is
to avoiding hitting the traps code, short-circuiting several steps along
the fast rectangular paths.
Fixes line-width-overlap.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
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);
- }
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>
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>
Step 1, fix the failings sighted recently by tracking clip-boxes as an
explicit property of the clipping and of composition.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
In order for custom context to automatically track when a pattern is
modify after being set on the context (and before it is used in an
operator), we need for there to be a callback when the pattern is
modified.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
_cairo_polygon_limit() had to be called immediately after
_cairo_polygon_init() (or never at all).
Merging the two calls is a simple way to enforce this rule.
Use inline accessors to hide the flags in the code.
This ensures that flags that need additional computations (example:
is_rectilinear for the fill case) are always used correctly.
Those paths were broken, as they didn't properly translate the polygon
to the destination size. And rather than adding lots of code that allows
translation, it's easier to just delete this code.
Note that the only user of the code was the GL backend anyway.
The extents clip regions that were created for unbounded operators were
not translated properly. This has been changed now.
This is a followup to 9ce8bef9d6.
Otherwise unbounded operators will clear the full surface.
Improves the score for the unbounded-operator test, in particular the
output for the test-fallback case.
I updated the Free Software Foundation address using the following script.
for i in $(git grep Temple | cut -d: -f1 )
do
sed -e 's/59 Temple Place[, -]* Suite 330, Boston, MA *02111-1307[, ]* USA/51 Franklin Street, Suite 500, Boston, MA 02110-1335, USA/' -i "$i"
done
Fixes http://bugs.freedesktop.org/show_bug.cgi?id=21356
Stop the callers from guessing the origin of the clip surface by
reporting it explicitly! This enables the clip to bypass any rectangles
overlaid on top of the clip surface, which is common when the backends
limit the clip to the extents of the operation -- but irrelevant to the
actual content of the clip mask
_cairo_clip_get_surface() now returns a borrowed reference to the cached
surface on the clip, so we must not destroy it - as Carlos pointed out
when he hit the assert:
12:55 < KaL> ickle: cairo-surface.c:595: cairo_surface_destroy:
Assertion `((*&(&surface->ref_count)->ref_count) > 0)' failed.
12:56 < KaL> ickle: trying to render any pdf file with poppler glib demo
after installing cairo from git master
13:00 < KaL> ickle: well, it seems it has nothing ot do with poppler,
since it crashes in clearlooks src/clearlooks_draw.c:347
Revamp clipping in preparation for the removal of the low-level interface
and promote backend to use the higher levels. The principle here is that
the higher level interface gives the backend more scope for choosing
better performing primitives.
By preallocating in our data segment a couple of solid patterns for the
stock colours, it becomes more convenient when using those in surface
operations, such as when clearing.
This is a more useful definition that is able to individually track the
rectangles that compose the composite operation. This will be used by
the specialist compositors as a means to perform the common extents
determination for an operation.
As a simple step to ensure that we do not inadvertently modify (or at least
generate compiler warns if we try) user data, mark the incoming style
and matrices as constant.
Previously target device offsets were applied in cairo-surface.c which
could cause bugs when paths were taken as fallbacks, as for example
pointed out by ade55037ff and quick-fixed
by 79190d8985. The quick-fix is now
unnecessary and was removed.
Gah, that was a horrible mistake. It was a flawed hack to create Pixmaps
of the correct depth when cloning patterns for blitting to the xlib
backend. However, it had the nasty side-effect of discarding alpha when
targeting Window surfaces. The correct solution is to simply correct the
Pixmap of the desired depth and render a matching pattern onto the
surface - i.e. a reversal the current acquire -> clone. See the
forthcoming revised xcb backend on how I should have done it originally.
The goal is to create a similar surface with an identical format to
maximise performance in the subsequent blit, e.g. the xlib backend could
make the similar surface with an identical depth and so use the core
protocol, or the image surface could indeed make an identical copy so
that pixman only has to do a fast memcpy. As there is no direct method
to specify such a clone, we ask the backend for a similar surface of
identical content, and trust that the semantics are clear enough for the
intent to obvious.
_cairo_surface_fallback_paint() attempts to avoid a clipped operation if
we can convert the paint into a fill of the clipmask. However by calling
_cairo_surface_fill() we incur a double application of device offset to
the source, triggering various failures.
Company spotted this and managed to extract an excellent minimal test
case, test/clip-device-offset. This commit fixes that failure.
When combining a clip-mask with a subsurface, as when used to combine with
the composite mask, we need to pass the destination surface offset to the
clip so that the paths can be corrected for the new surface.
Fixes test/implicit-close
By forgetting the implicit-close when checking for rectilinear paths, we
tried to feed the triangle (and other diagclose) into the specialised
rectilinear tesselators which completely mishandled that final edge.
Always use spans, even for unaligned boxes. In the future (given a new
interface) we may want to emit the common unaligned box code more
efficient than a per-scanline computation -- but for now simply avoid the
requirements to write a temporary CPU buffer.
Under simple, yet common, conditions using a bounded operator and painting
with a single complex clip we can reduce the strength of that operation to
a fill. In effect this removes the need for a temporary mask for some
backends (GL, drm, xlib).
Add an even simpler sweep-line tessellator for rectangular trapezoids (as
produced by the rectilinear stoker and box filler).
This is so simple it even outperforms pixman's region validation code for the
purposes of path-to-region conversion.
For the simple cases where the clip is an unaligned box (or boxes), apply
the clip directly to the geometry and avoid having to use an intermediate
clip-mask.
First perform a simple geometric clip to catch the majority of cases where
an unaligned clip has been set outside the operation extents that can be
discarded without having to use an image surface.
This causes a dramatic increase of over 13x for the poppler-bug-12266
trace and little impact elsewhere for more sensible clippers.
