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.
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>
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>
I need to remember that the translation for the pattern matrix is the
inverse of the translation for drawing.
Fixes: subsurface-modify-parent
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Rather than store a command to copy from a reference of another recording
surface onto this, just replay the other recording surface.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Borrow the technique for installing a proxy-snapshot developed for
acquiring the image from a recording surface.
This prevents the cairo from exploding and using up all memory due to
infinite recursion, but it does break a few tests that perform
self-copies with differing transformations.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
I forgot that creating any image by defaults results in pixman
calloc'ing the pixel data and so cairo helpfully sets the is-clear flag
on the surface.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Rather than compress the copies into a clip + copy, iterate over and
perform each copy separately so as to avoid the confusion for
window-to-window copies and the solitary GC->pCompositeClip.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As _cairo_surface_get_source() returns the limits of the source, a chunk
of code to query the source extents became redundant.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
