| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
The function computed the composite rectangles wrong and was only used
in a gl fallback anyway. So instead of trying to fix it, just remove it
and make sure gl doesn't fallback.
|
|
See the API documentation for that function about its intended purpose.
|
|
|
|
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.
|
|
color stops are not premultiplied so we need to handle them carefully
when comparing. The next step will be to make cairo_color_stop_t a
unique type to prevent this mistake again.
|
|
Lots upon lots of tiny fixes mixed in with experimental code. :(
|
|
The non-__GNUC__ version of the container_of macro would do wrong
when used like container_of(...)-> because '->' binds tighter
than the cast in the container_of macro. Adding an additional
set of parantheses fixes this.
|
|
|
|
Saves the memory allocation for the array, and the overhead of
maintaining the area for both insertions and more importantly deletes.
|
|
In order to reuse the original image as the pixman pattern, then the
entire operation must be wholly contained within the extents of the
image (including subsurfaces) and be reducible to an untransformed
REPEAT_NONE.
|
|
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
|
|
|
|
Due to slow memory speed, 16bpp color depth is still very popular on mobile
devices. Maemo5 is also using 16bpp color depth.
|
|
We were exposing the actual value of CAIRO_FORMAT_INVALID
through API functions already, so it makes sense to just
go ahead and put it in the cairo_format_t enum.
|
|
Split into a general cairo_image_surface_coerce() that coerces to one of
the 3 supported formats (ARGB32, RGB24, A8) based on content and the
more general cairo_image_surface_coerce_to_format() that coerces to a
specified format.
|
|
Fixes test suite failure
|
|
On my Core2, the library version of lround() is faster than our
hand-rolled non-floating point implementation. So only enable our code
if we are trying to minimise the number of floating point operations --
even then, it would worth investigating the library performance first.
[Just a reminder that optimisation choices will change over time as our
hardware and software evolves.]
|
|
Still an experimental backend, it's now a little too late to stabilise
for 1.10, but this should represent a major step forward in its feature
set and an attempt to catch up with all the bug fixes that have been
performed on xlib. Notably not tested yet (and expected to be broken)
are mixed-endian connections and low bitdepth servers (the dithering
support has not been copied over for instance). However, it seems robust
enough for daily use...
Of particular note in this update is that the xcb surface is now capable
of subverting the xlib surface through the ./configure --enable-xlib-xcb
option. This replaces the xlib surface with a proxy that forwards all
operations to an equivalent xcb surface whilst preserving the cairo-xlib
API that is required for compatibility with the existing applications,
for instance GTK+ and Mozilla. Also you can experiment with enabling a
DRM bypass, though you need to be extremely foolhardy to do so.
|
|
As proof-of-principle add the nearly working demonstrations of using DRM
to render directly with the GPU bypassing both RENDER and GL for
performance whilst preserving high quality rendering.
The basis behind developing these chip specific backends is that this is
the idealised interface that we desire for this chips, and so a target
for cairo-gl as we continue to develop both it and our GL stack.
Note that this backends do not yet fully pass the test suite, so only
use if you are brave and willing to help develop them further.
|
|
Write a dedicated compositor for pixman so that we avoid the
middle-layer syndrome of surface-fallback. The major upshot of this
rewrite is that the image surface is now several times quicker for glyph
compositing, which dramatically improves performance for text rendering
by firefox and friends. It also uses a couple of the new scan
convertors, such as the rectangular scan converter for rectilinear
paths.
Speedups
========
image-rgba firefox-talos-gfx-0 342050.17 (342155.88 0.02%) -> 69412.44 (69702.90 0.21%): 4.93x speedup
███▉
image-rgba vim-0 97518.13 (97696.23 1.21%) -> 30712.63 (31238.65 0.85%): 3.18x speedup
██▏
image-rgba evolution-0 69927.77 (110261.08 19.84%) -> 24430.05 (25368.85 1.89%): 2.86x speedup
█▉
image-rgba poppler-0 41452.61 (41547.03 2.51%) -> 21195.52 (21656.85 1.08%): 1.96x speedup
█
image-rgba firefox-planet-gnome-0 217512.61 (217636.80 0.06%) -> 123341.02 (123641.94 0.12%): 1.76x speedup
▊
image-rgba swfdec-youtube-0 41302.71 (41373.60 0.11%) -> 31343.93 (31488.87 0.23%): 1.32x speedup
▍
image-rgba swfdec-giant-steps-0 20699.54 (20739.52 0.10%) -> 17360.19 (17375.51 0.04%): 1.19x speedup
▎
image-rgba gvim-0 167837.47 (168027.68 0.51%) -> 151105.94 (151635.85 0.18%): 1.11x speedup
▏
image-rgba firefox-talos-svg-0 375273.43 (388250.94 1.60%) -> 356846.09 (370370.08 1.86%): 1.05x speedup
|
|
|
|
Another step in bringing some sanity to our headers.
|
|
A quick and efficient method for extracting the set of boxes that
represent the path when stroked.
|
|
A quick and efficient method for extracting the set of boxes that
represent the path when filled.
|
|
Frequently we only need the coarse path bounds, so avoid walking over
the list of points once more as we can cheaply track the extents during
construction.
|
|
As pointed out by Benjamin Otte, these are expensive no-ops that we can
trivially detect, just so long as we remember the semantics of extend
modes.
|
|
By preallocating in our data segment a couple of solid patterns for the
stock colours, it becomes more convenient when using those in surface
operations, such as when clearing.
|
|
Fixes test/clear-source as proposed by Benjamin Otte.
|
|
This variant uses the Bentley-Ottmann algorithm to only maintain the
active edge list upon edge events and so can efficiently skip areas
where no change occurs. This means that it can be much quicker than the
Tor algorithm (which is still used to compute the coverages from the
active edges) for geometries consisting of long straight lines with few
intersections. However due to the computational overhead of the
Bentley-Ottmann event processing, for dense curvy paths, simply updating
the active edge list in sync with computing the coverages is a win. Due
to advantageous adaptive step size, the scan converter can be run at a
much higher subsampling with little extra overhead compared with Tor,
currently it uses a 256x256 subsampling grid to avoid any impedance
mismatch with path precision.
Given the current status of implementations, this scan converter [botor]
is likely to be advantage where detecting large regions of unchanged
span data will result in improved performance, for instance the drm
backends which convert the scan data into rectangles.
|
|
Extend the special case rectilinear tessellator to also produce boxes.
|
|
Extend the special case rectangular tessellator to handle generation of
cairo_boxes_t.
|
|
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.
|
|
It is quite common amongst our geometry to have rows of repeated span
data, for example a rounded rectangle will have repeating data between
the top and bottom rounded corners. By passing the repeat length to the
renderers, they may be able to use that information more efficiently,
and the scan converters can avoid recomputing the same span data.
|
|
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.
|
|
This was never used, so remove the complexity from the interface.
|
|
As a simple step to ensure that we do not inadvertently modify (or at least
generate compiler warns if we try) user data, mark the incoming style
and matrices as constant.
|
|
A pending commit will want to include some utility code from cairo and
so we need to extricate the error handling from the PLT symbol hiding.
|
|
Add some auxiliary functions to cairo-stroke-style to compute
properties of the dashed patterns (period, "on" coverage) and to
generate approximations when the dash pattern is sub-tolerance.
These functions are used in cairo-path-stroke to simplify dash
patterns stroked by cairo.
Fixes dash-infinite-loop
See http://bugs.freedesktop.org/show_bug.cgi?id=24702
|
|
The glibc versions are slow in utf8 locales.
|
|
The new name is more descriptive than the rather opaque meta surface.
Discussed with vigour on the mailing list and #cairo:
http://lists.cairographics.org/archives/cairo/2009-July/017571.html
|
|
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.
|
|
A nasty surprise whilst profiling is that performing redundant clear
operations is extremely painful. We can mitigate this somewhat by
tracking the cleared state of surfaces and skipping repeated attempts to
clear a surface.
|
|
Gah, that was a horrible mistake. It was a flawed hack to create Pixmaps
of the correct depth when cloning patterns for blitting to the xlib
backend. However, it had the nasty side-effect of discarding alpha when
targeting Window surfaces. The correct solution is to simply correct the
Pixmap of the desired depth and render a matching pattern onto the
surface - i.e. a reversal the current acquire -> clone. See the
forthcoming revised xcb backend on how I should have done it originally.
|
|
Return FALSE when the pixman format does not support ARGB masks. In
particular, return FALSE for YUV formats.
|
|
Implement cheap calculation of glyph extents to see whether we can discard
the clip region. This is effective around 50% of the time for firefox (and
makes the xtrace so much neater).
|
|
If we have to rasterise a pattern for use by PS/PDF (for example, to
satisfy CAIRO_EXTENT_PAD) then only generate an image large enough to
cover the operation extents. We ensure tight coverage by computing the
extents afresh - we could do this lazily in the future, but we can not
rely on the bounds as computed by the analysis surface as for native
operations they may not be tight.
|
|
|
|
Always use spans, even for unaligned boxes. In the future (given a new
interface) we may want to emit the common unaligned box code more
efficient than a per-scanline computation -- but for now simply avoid the
requirements to write a temporary CPU buffer.
|
|
|
|
Add an even simpler sweep-line tessellator for rectangular trapezoids (as
produced by the rectilinear stoker and box filler).
This is so simple it even outperforms pixman's region validation code for the
purposes of path-to-region conversion.
|
