| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
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. :)
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
A common requirement is the fast upload of pixel data. In order to
allocate the most appropriate image buffer, we need knowledge of the
destination. The most obvious example is that we could use a
shared-memory region for the image to avoid the transfer cost of
uploading the pixels to the X server. Similarly, gl, win32, quartz...
The other side of the equation is that for manual modification of a
remote surface, it would be more efficient if we can create a similar
image to reduce the transfer costs. This strategy is already followed
for the destination fallbacks and this merely exposes the same
capability for the application fallbacks.
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>
|
|
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>
|
|
|
|
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
|
|
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.
|
|
b7550bf0 introduced a regression when user fonts are rendered to a
rotated context.
|
|
The PDF file referenced by bug 26186 contains a Type 3 font with non
identity font matrix and a "1/2" glyph created by drawing the "1" and
"2" from a Type 1 font. This combination exposed a bug in the font
scale and glyph position in _cairo_type3_glyph_surface_show_glyphs
when printing user font glyphs.
|
|
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.
|
|
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.
|
|
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
|
|
Replaying a meta surface can be achieved by using it as a source for a
cairo_paint() so exporting a separate API is unnecesary and confusing.
So after consulting Chris and Carl, we decided to remove the function
again.
|
|
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.
|
|
Perform an error check after creating a scaled-font to prevent operations
on a nil-object.
|
|
Propagate error from the stream when creating the surface and add status
guards before writing to the potential nil object.
|
|
Be careful not to pass an error object down to emit_image() hook,
propagate the error instead. This relieves the burden of the error check
from the callee -- which was causing an assertion failure in the ps
backend.
|
|
When coercing from one image format to another we performed a paint
operation using a temporary context - this is overkill as we can just call
_cairo_surface_paint() directly.
|
|
A surface will have the chance to use span rendering at cairo_fill()
time by creating a renderer for a specific combination of
pattern/dst/op before the path is scan converted. The protocol is to
first call check_span_renderer() to see if the surface wants to render
with spans and then later call create_span_renderer() to create the
renderer for real once the extents of the path are known.
No backends have an implementation yet.
|
|
Use the gcc likelihood annotation to indicate that allocation failures are
extremely unlikely.
|
|
The error paths should be hit very rarely during normal operation, so mark
them as being unlikely so gcc may emit better code.
|
|
Add a "cairo_rectangle_int_t *extents" argument to to the following
backend functions:
paint
mask,
stroke
fill
show_glyphs
show_text_glyphs
This will be used to pass the extents of each operation computed by
the analysis surface to the backend. This is required for implementing
EXTEND_PAD.
|
|
Tightly scope the output stream.
|
|
Only copy the pattern if we need to modify it, e.g. preserve a copy in a
snapshot or a soft-mask, or to modify the matrix. Otherwise we can
continue to use the original pattern and mark it as const in order to
generate compiler warnings if we do attempt to write to it.
|
|
This allows user-fonts to use glyph 0 when embedding in PS/PDF.
According to ISO32000 Type 3 fonts do not require a notdef glyph.
|
|
After discussing the scaled font locking with Behdad, it transpired that it
is not sufficient for a font to be locked for the lifetime of a scaled glyph,
but that the scaled font's glyph cache must be frozen for the glyph'
lifetime. If the cache is not frozen, then there is a possibility that the
glyph may be evicted before the reference goes out of scope i.e. the glyph
becomes invalid whilst we are trying to use it.
Since the freezing of the cache is the stronger barrier, we remove the
locking/unlocking of the mutex from the backends and instead move the
mutex acquisition into the freeze/thaw routines. Then update the rule on
acquiring glyphs to enforce that the cache is frozen and review the usage
of freeze/thaw by all the backends to ensure that the cache is frozen for
the lifetime of the glyph.
|
|
When looking up the glyph in the shared scaled_font glyph cache, the
caller is required to have taken the scaled_font->mutex.
|
|
Images in PDF are scaled to a unit square. In PS we set the
ImageMatrix to do the same. When the image is painted we scale the
graphics state to paint the image at the right size. In the case of
Type 3 fonts consisting of bitmap images we want to paint the images
at their original size so we scale the graphics state by the image
width and height.
The bug was that we were scaling by the width/height in the glyph
metrics. For non rotated fonts this worked. However for rotated fonts
the width/height of the glyph images may be larger than the
width/height in the glyph metrics. This resulted in a Type 3 font
where the glyph images were scaled slightly smaller than they should
have been.
|
|
|
|
|
|
This function emits the glyph to a null stream with the side effect
that other glyphs referenced by this user-font glyph will be added to
the font subsets.
|
|
Quick summary of changes:
- Move list of cairo source files out of src/Makefile.am and into
src/Sources.mk,
- Generate files src/Config.mk and src/Config.mk.win32 that choose
the right set of source files and headers based on configured
backends and features. This drastically simplifies building
using other build systems. The src/Makefile.win32 file needs
to be updated to reflect these changes.
- Add README files to various directories,
- Add toplevel HACKING file.
|
|
Return the error status from ->emit_image().
|
|
There does not appear to be any way of emulating PDF inline images in
PostScript so we call back to the PS or PDF surface to emit the image.
|
|
show_glyphs inside a Type 3 font currently results in a fallback
image. Some refactoring is required before font subsets can be created
while emitting all the font subsets.
|
