Documentation comments should always start with "/**" and end with
"**/". This is not required by gtk-doc, but it makes the
documentations formatting more consistent and simplifies the checking
of documentation comments.
The following Python script tries to enforce this.
from sys import argv
from sre import search
for filename in argv[1:]:
in_doc = False
lines = open(filename, "r").read().split("\n")
for i in range(len(lines)):
ls = lines[i].strip()
if ls == "/**":
in_doc = True
elif in_doc and ls == "*/":
lines[i] = " **/"
if ls.endswith("*/"):
in_doc = False
out = open(filename, "w")
out.write("\n".join(lines))
out.close()
This fixes most 'documentation comment not closed with **/' warnings
by check-doc-syntax.awk.
This is initially based around the requirements for handling internal
fallbacks to the image compositor and reducing the number of pixels
required to be transferred.
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. :)
There are some inkscape bugs reporting very slow rendering of inkscape
generated PDFs (inkscape uses cairo for PDF output). These bugs are
caused by cairo specifying a page sized bounding box in XObjects and
Patterns. PDF renderers usually use the BBox as the image size when
compositing. As PDFs generated from SVG tends to use a lot of XObjects
and Patterns this can lead to very long rendering times.
These three patches tighten up all the BBoxes in PDF output.
In step 1 of speeding up stroking, we introduce contours as a means for
tracking the connected edges around the stroke. By keeping track of
these chains, we can analyse the edges as we proceed and eliminate
redundant vertices speeding up rasterisation.
Coincidentally fixes line-width-tolerance (looks like a combination of
using spline tangent vectors and tolerance).
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Another logging passthrough surface that records the style of operations
performed trying to categorise what is slow/fast/important.
In combination with perf/cairo-analyse-trace it is very useful for
understanding what a trace does. The next steps for this tool would be
to identify the slow operations that the trace does. Baby steps.
This should be generally useful in similar situations outside of perf/
and should be extensible to become an online performance probe.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Still hopelessly broken. Requires compiling cairo to use static linking
and then still requires manual linkage to workaround libtool. Lots of
functionality is still absent - we need to either find analogues to some
Cairo operations or implement fallbacks - but it is sufficient to
investigate how Skia functions in direct comparison with Cairo for
tessellation/rasterisation.
Caveat emptor.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
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.
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>
Allow a backend to completely reimplement the Cairo API as it wants. The
goal is to pass operations to the native backends such as Quartz,
Direct2D, Qt, Skia, OpenVG with no overhead. And to permit complete
logging contexts, and whatever else the imagination holds. Perhaps to
experiment with double-paths?
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Using double precision for gradient extreme objects ensures that they
are preserved as specified when constructing the gradient pattern.
Fixes huge-linear, huge-radial.
Fixes part of https://bugs.freedesktop.org/show_bug.cgi?id=32215
Add the mesh pattern type and an error status to be used to report an
incorrect construction of the pattern.
Update the backends to make them ready to handle the new pattern type,
even if it cannot be created yet.
This will be a common function used by the quartz, ps, and pdf
backends when rewriting EXTEND_REFLECT/REPEAT gradients in terms
of EXTEND_PAD gradients.
Reviewed-by: M Joonas Pihlaja <jpihlaja@cc.helsinki.fi>
Using _cairo_path_fixed_interpret_flat() greatly simplifies the path
to polygon conversion (because it already converts curve_to's to
line_to's).
This commit also removes the optimization which merges two consecutive
lines if they have the same slope, because it's unlikely (since it
should already happen during path construction), it doesn't provide
better performance (at least not measurable with the currently
available cairo-traces) and bloats the code.
Array snapshots are not used anymore and just bloat the implementation
of cairo_array_t.
In particular, double indirection was needed to implement array
snapshots, as explained in c786853993.
What we want to use is size_t, but we don't want the implied POSIX
dependency. However, POSIX does say that size_t is an unsigned integer
that is no longer than a long, so it would appear safe to use an
unsigned long as a replacement. Safer at least than unsigned int.
I did this manually so I could review the docs at the same time.
If anyone finds typos or other mistakes I did, please complain to me (or
better: fix them).
This adds internal API to retrieve the LCD filtering parameters from
fontconfig, or as set on the Screen, and feed them to FreeType when
rendering the glyph.
References:
Bug 10301 - LCD filtering patch
https://bugs.freedesktop.org/show_bug.cgi?id=10301
Tested-by: Brandon Wright <bearoso@gmail.com>
Forward-ported-by: Robert Hooker <sarvatt@gmail.cm>
ickle: The API is clearly not ready for public consumption, the enum are
poorly named, however this stands by itself as enabling system wide
properties.
Commit 8d67186cb2 caches whether the device
transform is identity on context creation. However, the api is quite lax
and allows the user to modify the device transform *after* he has
started to use the surface in a context, as apparently WebKit does.
Since this is not the only instance where we may need to invalidate
caches if the user modifies state, introduce a simple mechanism for
hooking into notifications of property changes.
Fixes test/clip-device-offset.
Hopefully reduce the occurrence of the confusion between the
premultiplied shorts in cairo_color_t and the non-premultiplied shorts
in cairo_color_stop_t.
The existence of the two separate types is debatable and open for
review.
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
By tracking which fields of information are already available on the
scaled_glyph we can more efficiently determine if we already have the
requested fields. This reduces from about 6 conditionals to one, and
reduces the function overhead by ~20% -- which has a measurable
improvement on glyph benchmarks.
Currently we use cairo_traps_t to also pass around arrays of boxes. This
is woefully inefficient in terms of storage, but also means that we
repeatedly have to verify that the traps are a set of boxes. By
explicitly passing around a cairo_boxes_t we avoid the semantic loss.
This will be heavily used in pending commits.
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.
The device is a generic method for accessing the underlying interface
with the native graphics subsystem, typically the X connection or
perhaps the GL context. By exposing a cairo_device_t on a surface and
its various methods we enable finer control over interoperability with
external interactions of the device by applications. The use case in
mind is, for example, a multi-threaded gstreamer which needs to serialise
its own direct access to the device along with Cairo's across many
threads.
Secondly, the cairo_device_t is a unifying API for the mismash of
backend specific methods for controlling creation of surfaces with
explicit devices and a convenient hook for debugging and introspection.
The principal components of the API are the memory management of:
cairo_device_reference(),
cairo_device_finish() and
cairo_device_destroy();
along with a pair of routines for serialising interaction:
cairo_device_acquire() and
cairo_device_release()
and a method to flush any outstanding accesses:
cairo_device_flush().
The device for a particular surface may be retrieved using:
cairo_surface_get_device().
The device returned is owned by the surface.
The first iteration of COW snapshotting always made an initial copy when
the snapshot was requested (and reused that copy until the surface was
modified). However, in a few circumstances we can avoid even that copy
so long as the surface is still alive and unmodified between the
snapshotting and its use. In order to do so, we need a new proxy surface
that can automatically perform the copy if the target should disappear
prior to use.
A subsurface is a region of another surface that may be used either to
restrict the writable area of a context or the readable extents of a
source. Whilst writing, access to the exterior of the subsurface is
prevented via clipping and when used as a source reads from the exterior
of the subsurface are governed via the extend mechanism of the pattern.
Within our code base we carried a few hacks to utilize the component
alpha capabilities of pixman, whilst not supporting the concept for our
own masks. Thus we were setting it upon the pixman_image_t that we
passed around through code that was blissfully unaware and indeed the
component-alpha property was forgotten (e.g. upgrading glyph masks).
The real issue is that without explicit support that a pattern carries
subpixel masking information, that information is lost when using that
pattern with composite. Again we can look at the example of compositing
a sub-pixel glyph mask onto a remote xlib surface for further failure.
The early discard checked if the line was below the last clip-box, or if
above the first. However, the clip-boxes are only sorted on by the bottom
(not the strict XY-banded sort of the regions) and so this was erroneously
discarding lines.
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.
We refactor the surface fallbacks to convert full strokes and fills to the
intermediate polygon representation (as opposed to before where we
returned the trapezoidal representation). This allow greater flexibility
to choose how then to rasterize the polygon. Where possible we use the
local spans rasteriser for its increased performance, but still have the
option to use the tessellator instead (for example, with the current
Render protocol which does not yet have a polygon image).
In order to accommodate this, the spans interface is tweaked to accept
whole polygons instead of a path and the tessellator is tweaked for speed.
Performance Impact
==================
...
Still measuring, expecting some severe regressions.
...
Handling clip as part of the surface state, as opposed to being part of
the operation state, is cumbersome and a hindrance to providing true proxy
surface support. For example, the clip must be copied from the surface
onto the fallback image, but this was forgotten causing undue hassle in
each backend. Another example is the contortion the meta surface
endures to ensure the clip is correctly recorded. By contrast passing the
clip along with the operation is quite simple and enables us to write
generic handlers for providing surface wrappers. (And in the future, we
should be able to write more esoteric wrappers, e.g. automatic 2x FSAA,
trivially.)
In brief, instead of the surface automatically applying the clip before
calling the backend, the backend can call into a generic helper to apply
clipping. For raster surfaces, clip regions are handled automatically as
part of the composite interface. For vector surfaces, a clip helper is
introduced to replay and callback into an intersect_clip_path() function
as necessary.
Whilst this is not primarily a performance related change (the change
should just move the computation of the clip from the moment it is applied
by the user to the moment it is required by the backend), it is important
to track any potential regression:
ppc:
Speedups
========
image-rgba evolution-20090607-0 1026085.22 0.18% -> 672972.07 0.77%: 1.52x speedup
▌
image-rgba evolution-20090618-0 680579.98 0.12% -> 573237.66 0.16%: 1.19x speedup
▎
image-rgba swfdec-fill-rate-4xaa-0 460296.92 0.36% -> 407464.63 0.42%: 1.13x speedup
▏
image-rgba swfdec-fill-rate-2xaa-0 128431.95 0.47% -> 115051.86 0.42%: 1.12x speedup
▏
Slowdowns
=========
image-rgba firefox-periodic-table-0 56837.61 0.78% -> 66055.17 3.20%: 1.09x slowdown
▏
The meta-surface is a vital tool to record a trace of drawing commands
in-memory. As such it is used throughout cairo.
The value of such a surface is immediately obvious and should be
applicable for many applications. The first such case is by
cairo-test-trace which wants to record the entire graph of drawing commands
that affect a surface in the event of a failure.
The structure is already exposed, so just expose the
constructors/destructors in order to enable caches to be embedded and
remove a superfluous malloc.
Usually, rectangles are more useful than boxes, so regions should only
expose rectangles in their public API.
Specifically,
_cairo_region_num_boxes becomes _cairo_region_num_rectangles
_cairo_region_get_box becomes _cairo_region_get_rectangle
Remove the cairo_box_int_t type
Jeff Muizelaar pointed out that the severe overallocation implicit in the
current version of the glyph cache is obnoxious and prevents him from
accepting the trunk into Mozilla. Jeff captured a trace of scaled font
and glyph usage during a tp run and presented his analysis in
http://lists.cairographics.org/archives/cairo/2009-March/016706.html
Using that data, the design was changed to allocate pages of glyphs from a
capped global pool but with per-font hash tables. This should allow the
glyph cache to have tight memory bounds with fair allocation according to
usage. Note that both the old design and the 1.8 glyph cache had
essentially unbounded memory constraints, since each scaled font could
cache up to 256 glyphs (1.8) or had a reserved page (old), with no limit
on the number of active fonts. Currently the eviction policy is a simple
random strategy, this gives a 'fair' allotment of the cache, but a LRU
variant might perform better.
On a sample run of firefox-3.0.7 perusing BBC news in 32 languages:
1.8: cache allocation 8190x, ~1.2 MiB; elapsed 88.2s
old: cache allocation 771x, ~13.8 MiB; elapsed 81.7s
lean: cache allocation 433x, ~1.8 MiB; elapsed 82.4s
