Despite copying across the font options from the PDF backend, it still
looks like the image surface is override the glyph placement... Odd.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Recently I began using the surface->snapshot_of member of a subsurface
to cache a target representation of the current subsurface. More
recently, I discovered this caused an assertion failure in epiphany, and
probably other GTK3 based programs.
Throwaway the assertion and trust that the programmer doesn't make any
mistakes...
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Only texture surfaces need to have a depth-stencil attachment.
The default framebuffer is responsible for managing its own
depth and stencil attachments.
The (dst_x, dst_y) parameters passed to the XRenderCompositeText are
misleading and do not perform any adjustment, so we have to do it
ourselves.
Fixes clip-operator
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Both combine-with-clip functions now take care of any intersection with
clip boxes so the result would be to have overdrawn the unaligned clip
box mask twice.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If we have more than a single box, run the boxes intersection as a
post-processing step on the clip polygon, as it should be faster than
doing it inline.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
And not the device_transform of the target. This smells fishy, but
appears to make the test suite happy.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
In theory, this should be more cache efficient and allow us to trim the
operation to the width of row, shaving a few texel fetches. The cost is
that we cause pixman to evaluate the composite operation per-row. This
should only be a temporary solution until we can do something better
through pixman...
On a i5-2520m, ymmv,
firefox-fishtank 64585.38 -> 56823.41: 1.14x speedup
swfdec-fill-rate 1383.24 -> 1665.88: 1.20x slowdown
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reducing the number of passes has the usual change in the antialiasing
side-effects, as well as the boon of being faster (and theorectically more
accurate through reduced loss of dynamic range.)
On an i5-2520m:
swfdec-giant-steps-full 3240.43 -> 2651.36: 1.22x speedup
grads-heat-map 166.84 -> 136.79: 1.22x speedup
swfdec-giant-steps 940.19 -> 796.24: 1.18x speedup
ocitysmap 953.51 -> 831.96: 1.15x speedup
webkit-canvas-alpha 13924.01 -> 13115.70: 1.06x speedup
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If we have a curvy polygon, we can expect to generate lots of short
trapezoids. However, we may be able to reduce the transport size by
converting them into a set of boxes instead.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This trick only seems effective with mono-rasterisation, with a win of
about 10% for tiger-demo --antialias=none. At other antialias setting,
performance is reduced.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
We suffer from the large overhead in calling pixman_image_composite32
per-span, but even will that overhead it is a net win with the usual
caveat about cache efficiency and function call overhead.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The actual span rasterisers may be able to specialise if they know that
the spans will be pixel aligned.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
cairo_xcb_device_debug_cap_xrender_version is called by xlib-xcb's
cairo_xlib_device_debug_cap_xrender_version and thus must be marked slim_hidden.
Checking .libs/libcairo.so for local PLT entries
0000000000306ff8 0000024200000007 R_X86_64_JUMP_SLOT
000000000009e720 cairo_xcb_device_debug_cap_xrender_version + 0
FAIL: check-plt.sh
Signed-off-by: Uli Schlachter <psychon@znc.in>
The documentation was apparently copied from
cairo_xcb_device_debug_cap_xrender_version without changing "XCB" into "Xlib".
Signed-off-by: Uli Schlachter <psychon@znc.in>
Clearly demonstrated by using the test-base with the recording surfaces
and exemplified by the fallback-resolution with PDF, which is *almost*
fixed!
We're very close to making a release candidate for 1.12 now...
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The clipping code was modified to handle partial boxes itself, so update
the base compositor to simply use the core clipping code and avoid
double application.
In order to match the reference image we need complete coverage, and the
purpose of the test is to check non-integer scaling of replays rather
than handling of the clip pixels. That partial coverage is better tested
elsewhere.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Even for a vertical edge, we still need to bias the error term otherwise
later we will find the error term is too larger and advance a pixel on
every row.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If the mask does not intersect the clip, then there is no drawing to be
performed and we can report NOTHING_TO_DO.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
When estimating the maximum number of spans required for a particular
width, we need to include a closing span.
Reviewed-by: Zhigang Gong <zhigang.gong@linux.intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Currently you can only specify that a cairo_ft_font_face_t should
synthesize a font (to make a bold variant) through an FcPattern. That is
direct consumers of the public cairo-ft API have no control over the
synthesize options.
Rectify this by creating some public API to allow control over the
synthesis flags, and include the ability to construct an oblique as
well an embolden font.
Based on a patch by Deokjin Kim <deokjin81.kim@samsung.com>.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Not 100% improvement, there are still a variety of failures with
GLXWindows, but getting there. At least it fixes more things than its
breaks...
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Complete the task started in cd4b2d843b by
remembering to compute the insertion hash on the original font face as
well as the lookup hashes. Also take advantage by deferring resolution
of the implementation for the font face until after we fail to find an
already constructed scaled font.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As the path is converted to fixed-point prior to application of the
replay scale factor, we currently do anticipate some loss in precision
and slight difference in antialiasing.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Ordinary patterns have their device offsets pre-baked into the pattern
matrix. The difference with raster patterns is that the surface is
generated upon use by the pdf,ps and so its device offset is not known
until then.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
PDF/PS do not have the concept of aliased rendering, so like many of the
other rasterisation tests, a1-line-width cannot be tested satisfactorily
on those backends.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
