Age | Commit message (Collapse) | Author | Files | Lines |
|
|
|
|
|
|
|
Exercise the extend modes with a clipped paint, because once upon a time
we had a bug...
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
When painting with an unbound source, we would miss that the clip
extents were smaller than the mask extents and remove the solitary clip
(believing we were bound by a tight mask). For painting this is
obviously wrong, and due to a combination of bugs that set the mask to
the bound extents and then the failure to spot when that mask was larger
than the clip.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
It is convenient if the user can simply enable the use of the commented
write-to-png operation just by removing the preceding '%'. However, to
do so we need to make sure that the line is stack-neutral and so need to
pop the surface that we place onto the stack after writing the png.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Similar to the minimum height property, is-vertical can only change
after an insertion or deletion event. So we only need to update the
flags after one of those events, so simply update it along side
min-height.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Time how long it takes to stroke and fill a single Bezier curve.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Continuing the theme of stressing the tessellators, draw lots of Bezier
curves!
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Some trivial cleanups that escaped my noticed during a tired review.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Saves having to fixup the pointers afterwards by only having to update
them on the list boundaries during merge.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
However, this is only useful for inserting multiple boxes within the
pixel, so we maintain the cached insert cursor as this speeds up the
general case (and aides this optimisation as well).
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Since we only allocate a pointer to the rectangle after it is started
and so decoupled from the start queue, we reuse the memory allocated for
the start queue for the stop binary heap.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Since we discard empty fill boxes whilst filling, we can also treat
horizontal/vertical lines as a filled box and so proceed with the
rectangular fast path in the presence of
cairo_rectangle (x, y, w, h)
with w == 0 || h == 0.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
A variant of many-strokes tries to answer the question of how much
overhead is there in stroking, i.e. if we fill an equivalent path to a
set of strokes, do we see an equivalence in performance?
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Fixes: map-all-to-image, map-bit-to-image for image16
Signed-off-by: Uli Schlachter <psychon@znc.in>
|
|
User shouldn't be able to use extents that are not completely inside of the
surface's extents.
Signed-off-by: Uli Schlachter <psychon@znc.in>
|
|
cairo_surface_unmap_image() destroys the image that was passed to it. Since
xlib-xcb calls cairo_surface_unmap_image() again for the underlying xcb surface,
the surface was destroyed twice.
Work around this problem by incrementing the image's reference count via
cairo_surface_reference().
No idea why I didn't catch this problem when implementing these functions, I'm
sure I ran the relevant tests. :-(
lt-cairo-test-suite: cairo-surface.c:853: cairo_surface_destroy: Assertion
`((*&(&surface->ref_count)->ref_count) > 0)' failed.
Fixes: map-to-image-fill map-bit-to-image map-all-to-image
Signed-off-by: Uli Schlachter <psychon@znc.in>
|
|
Signed-off-by: Uli Schlachter <psychon@znc.in>
|
|
The majority of intersections are with the nearest neighbour only, or
within a few neighbours (in a dense intersection of lines) so if walk
the active list backwards and find the new place to insert upon an
intersection it is faster than performing a mergesort afterwards.
Given enough intersections, the win is quite huge (15-20% on many-strokes).
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
For completeness, also compare [aligned] horizontal and vertical
strokes.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
An intersection variant to exercise the stroker with many, many lines. A
silly benchmark, but a popular one in the wild.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Checks that coincident end-points are not converted to joins. It briefly
passed through my mind that was a good thing...
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Ensures that only a box that covers the centre pixel is filled with
antialiasing disabled.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Another variant of the utility apps that understand the output of
_cairo_debug_print_polygon().
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
The complexity in this shape is that the stroke is reversed upon
itself and retraces the same path in the opposite direction.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
A second relatively simple closed concave shape, all the better for
debugging with.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
A simple convex shape, useful for debugging.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
The end of the clip path list is marked with NULL, so we should stop
iterating paths when we reach it.
The assertion was meant to check if paths had the same content, not if
they have the same address.
Fixes clip-fill-rule and clip-twice in cairo-quartz.
|
|
If there are no clip boxes, we do not need to emit an empty clip which
only confuses the users of the surface-clipper.
Spotted by Andrea Canciani and cairo-quartz
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Are the reference images correct? Discuss.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
PS files printed from PDF do not have a cmap in the subsetted
fonts. If the unicode mapping has ben supplied by _show_text_glyphs we
should use this instead of the reverse lookup to determine if the
glyph is a latin chartacter.
|
|
to ensure that when the PS is converted to PDF the text can be extracted.
|
|
|
|
|
|
As we use this a performance benchmark, it behooves us to check that we
are rendering it correctly.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
In this case we do not need to copy anything, but may still need to
re-orientate the box.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
cairo_surface_create_similar_image, cairo_surface_map_to_image and
cairo_surface_unmap_image were added in
a69335a84eb9225b477cc8c753470eb3805b852c.
|
|
Recently cairo_surface_create_similar_image(), cairo_surface_map_to_image() and
cairo_surface_unmap_image() were introduced. However, the documentation was
slightly misleading and recommended a wrong usage.
Signed-off-by: Uli Schlachter <psychon@znc.in>
|
|
This fixes weird and occasional build failures when updating the source, e.g.:
cairo-perf-micro.o:(.rodata+0xb0): undefined reference to `hash_table'
Signed-off-by: Uli Schlachter <psychon@znc.in>
|
|
This implements create_similar_image, map_to_image and unmap.
Signed-off-by: Uli Schlachter <psychon@znc.in>
|
|
The fallback code assumed that the caller mapped the complete surface to an
image. If only parts of a surface were mapped, the code didn't correctly
translate and clip its operations.
Fixes map-bit-to-image for xlib-xcb and improves the result for recording.
Thanks to Chris Wilson for some simplifications.
Signed-off-by: Uli Schlachter <psychon@znc.in>
|
|
Printing PDFs with large monochrome or grayscale images would result
in the images being blown up to 24-bit color images. Some printers are
very slow to print huge color images.
|