In this bug a Type 3 font contains a dash glyph. The dash glyph
consists of an 82x2 image. The image height, when scaled to user space,
is < 1 resuling in the drawing operation for the image being culled.
https://bugs.freedesktop.org/show_bug.cgi?id=94615
New implementations of _cairo_pattern_sampled_area and _cairo_pattern_get_extents
which produce a more accurate bounding box. These do not depend on side-effects
of analyze_filter, can handle different horizontal and vertical scales, filters
wider than 1 for down-scaling, and compute a somewhat tighter bounding box
in most cases.
I removed the pad output of _cairo_pattern_analyze_filter as it is unused.
Reviewed-by: Bryce Harrington <b.harrington@samsung.com>
We need to be more careful when trying to discard a clip to be sure that
it is truly not required. In particular, we need to not throw a way a
clip region when it has more than one box intersecting the mask.
Reported-by: Alexander Larsson
Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=697357
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
So that the composite-rectangles remains consistent with the reduced
clip in case the individual compositors try to optimise their rendering
strategies based on the reduced clip and the overall extents.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If the font metrics appear broken, i.e. key values are being reported as
zero, skip approximating the bbox of the glyph string.
References: https://bugs.freedesktop.org/show_bug.cgi?id=50688
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The SOURCE and CLEAR are the odd pair in Cairo's range of operators that
are bound by the shape/mask, but are unbound by the source. This
regularly leads to bugs as only track the bound/unbound rectangles and
confuse the meaning when bound only by the mask.
What is required is that the unbound extents in this case is only
trimmed by the mask (the bounded extents are still the intersection of
all).
Fixes bug-source-cu
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
And only upload the parts of the image that are modified during the
fallback. I have to keep reminding myself that the goal is always to
reduce the amount of fallbacks required...
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
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. :)
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>
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>
Computing the exact bbox of the glyphs and whether they are overlapped
is expensive. However, we can often check whether they are visible just
by looking at the maximal extents of the fonts along with the bbox of
the positions; much cheaper.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
A demonstration of step 2, improves performance for selected benchmarks
on selected GPUs by up to 30%.
firefox-fishbowl on snb {i5-2520m): 42s -> 29s.
firefox-talos-gfx on snb: 7.6 -> 5.2s.
firefox-fishbowl on pnv (n450): 380 -> 360s.
Whist this looks like it is getting close to as good as we can achieve,
we are constrained by both our API and Xrender and fishbowl is about 50%
slower than peak performance (on snb).
And it fixes the older performance regression in firefox-planet-gnome.
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>
on src/cairo-composite-rectangles.c
The extent of the operation can be larger than the source if
the operator is not bounded by the source.
Fixes clip-unbounded, operator-source, surface-pattern-operator
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
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.
