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
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.
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.
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
▏
Damian Frank noted
[http://lists.cairographics.org/archives/cairo/2009-May/017095.html]
a performance problem with an older XServer with an
unaccelerated composite - similar problems will be seen with non-XRender
servers which will trigger extraneous fallbacks. The problem he found was
that painting an ARGB32 image onto an RGB24 destination window (using
SOURCE) was going via the RENDER protocol and not core. He was able to
demonstrate that this could be worked around by declaring the pixel data as
an RGB24 image. The issue is that the image is uploaded into a temporary
pixmap of matching depth (i.e. 32 bit for ARGB32 and 24 bit for RGB23
data), however the core protocol can only blit between Drawables of
matching depth - so without the work-around the Drawables are mismatched
and we either need to use RENDER or fallback.
This patch adds a content mask to _cairo_surface_clone_similar() to
provide the extra bit of information to the backends for when it is
possible for them to drop channels from the clone. This is used by the
xlib backend to only create a 24 bit source when blitting to a Window.
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.
A little bit of sleep and reflection suggested that the use of
device_offset_[xy] was confusing and clone_offset_[xy] more consistent
with the function naming.
Previously the rule for clone_similar() was that the returned surface
had exactly the same size as the original, but only the contents within
the region of interest needed to be copied. This caused failures for very
large images in the xlib-backend (see test/large-source).
The obvious solution to allow cloning only the region of interest seemed
to be to simply set the device offset on the cloned surface. However, this
fails as a) nothing respects the device offset on the surface at that
layer in the compositing stack and b) possibly returning references to the
original source surface provides further confusion by mixing in another
source of device offset.
The second method was to add extra out parameters so that the
device offset could be returned separately and, for example, mixed into
the pattern matrix. Not as elegant, a couple of extra warts to the
interface, but it works - one less XFAIL...
Every time we assign or return a hard-coded error status wrap that value
with a call to _cairo_error(). So the idiom becomes:
status = _cairo_error (CAIRO_STATUS_NO_MEMORY);
or
return _cairo_error (CAIRO_STATUS_INVALID_DASH);
This ensures that a breakpoint placed on _cairo_error() will trigger
immediately cairo detects the error.
A few tests were failing due to clip_init_deep_copy() not being able to
clone the target surface. Before propagating the failure, this was being
silently ignored.
Copy the simple implementation from cairo-image-surface.
This is necessary to avoid many portability problems as cairoint.h includes
config.h. Without a test, we will regress again, hence add it.
The inclusion idiom for cairo now is:
#include "cairoint.h"
#include "cairo-something.h"
#include "cairo-anotherthing-private.h"
#include <some-library.h>
#include <other-library/other-file.h>
Moreover, some standard headers files are included from cairoint.h and need
not be included again.
This rectangle has regular integer values, not fixed-point values.
So the old name was horribly wrong and misleading, (and yes I think
it was even I that had suggested it).
All test targets now list an expected cairo_surface_type_t. Add notes
on current limitations of PDF/PS/meta-surface support that causes
CAIRO_CONTENT_COLOR similar surfaces of PDF and PS surfaces to be
returned as image surfaces.
Add cairo_internal_surface_type_t for the meta, paginated, and various
test surfaces.
The PS/PDF backends don't allow a content to be passed in right now, so they fail against the rgb24 tests, but the trivial addition to the constructors will allow them to pass all tests with both content values.
And new constructors (currently internal only) to create an image surface with a cairo_content_t rather than a cairo_format_t.
Add a cairo_content_t argument to the constructor.
Add a cairo_content_t to the constructor and use this content value when constructing intermediate image surfaces in acquire_source, show_page, copy_page, and snapshot.
Add image flattening by compositing over white, as is done in cairo-ps-surface.c.
Track changes to cairo-paginates-surface which now requires a cairo_content_t value (no change to public PS/PDF constructors yet).
Track change in meta-surface and paginated-surface interfaces by now accepting a cairo_content_t rather than a cairo_format_t.
Ignore new output files (argb32 from pdf and ps as well as rgb24 from test-fallback, test-meta, and test-paginated).
Add new utility for flattening PNG images in order to generate the -argbf-ref.png images.
Add image_diff_flattened for comparing flattened output from PS and PDF backend with ARGB reference images by first blending the reference images over white.
Get rid of conditional, format-specific background-color initialization before running tests. Now uses ARGB(0,0,0,0) in all cases. Switch from specifying tests with a format value to specifying tests with a content value. Add support for a 'fake' COLOR_ALPHA_FLATTENED content for testing the PS and PDF output against a flattened version of the argb32 reference images (first blended over white).
Track change in cairo_ps_surface_create (now requires cairo_content_t value).
Adjust tests that draw in default (black) to first paint white so that the results are visible.
Adjust ARGB32 reference images for new white background for changed tests.
Adjust RGB24 reference images for new black background due to changed initialization (and the tests themselves being unchanged).
Refine the comment describing this test surface.
Add new test surface for exercising cairo_meta_surface.
Simplify the image and test_fallback targets by not using create_for_data. Allow for NULL cleanup target functions. Add support for the test_meta_surface.
