| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
kCGColorSpaceDefaultRGB.
The default RGB colorspace must be converted to the GPU's colorspace
using CGColorTransformConvertUsingCMSConverter. Profiling has shown this
function to consume as much as 48% of a redraw cycle in gdk-quartz.
There seems to be no named colorspace that matches the one stored on the
display, so we use the one associated with the main display. This has
some risks for users with multiple monitors but in testing with my own
two-monitor setup, one of which is HDR and the other not, the colorspace
was the same for both.
This is applied to quartz surfaces created with
cairo_quartz_surface_create(); surfaces created with
cairo_quartz_surface_create_for_cg_context will inherit the colorspace
from the context.
In order to generate PNGs that look right I've converted the
existing debugging functions for writing a quartz surface to png
into private functions and wired cairo-boilerplate-quartz to use
them. Using the generic cairo routine produced washed-out PNGs.
Fixes https://gitlab.freedesktop.org/cairo/cairo/-/issues/330
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Use a CGBitmapContext mapping the underlying image surface's data instead
of maintaining a CGImage. Generalize the quartz surface snapshot mechanism
to work with both cairo_quartz_surface_t and cairo_quartz_image_surface_t
and to use the latter to get a CGContext around non-quartz surfaces.
Use this snapshot machanism to get a CGImageRef when needed from a
cairo_quartz_image_surface_t.
|
| |\
| |
| |
| |
| | |
More random doc fixes
See merge request cairo/cairo!437
|
| | | |
|
| |/
|
|
|
| |
../src/cairo-quartz-image-surface.c:149:24: warning: unused variable 'size' [-Wunused-variable]
const unsigned int size = surface->imageSurface->height * surface->imageSurface->stride;
|
| | |
|
| |
|
|
| |
(Thanks to Fred Bca)
|
| |
|
|
|
|
| |
Since we now copy the data that CGImage needs we don't need to
keep the surface around anymore, nor release it or the image in the
DataProviderReleaseCallback.
|
| |
|
|
|
|
|
|
| |
Snapshot the cairo_surface_t and copy the image data to provide to
the CGDataProvider so that it is independent of the cairo_surface_t's
lifetime.
Closes https://gitlab.freedesktop.org/cairo/cairo/-/issues/420
|
| |
|
|
|
|
|
|
|
|
| |
_cairo_malloc(0) always returns NULL, but has not been used
consistently. This patch replaces many calls to malloc() with
_cairo_malloc().
Fixes: fdo# 101547
CVE: CVE-2017-9814 Heap buffer overflow at cairo-truetype-subset.c:1299
Reviewed-by: Bryce Harrington <bryce@osg.samsung.com>
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes the following warning introduced in a recent commit reported by
~suv:
CC cairo-quartz-image-surface.lo
cairo-quartz-image-surface.c:382:37: warning: incompatible pointer types
passing 'cairo_quartz_image_surface_t *'
(aka 'struct cairo_quartz_image_surface *') to parameter of type
'const cairo_surface_t *' (aka 'const struct _cairo_surface *')
[-Wincompatible-pointer-types]
if (! _cairo_surface_is_quartz (surface)) {
^~~~~~~
./cairo-quartz-private.h:87:50: note: passing argument to parameter 'surface' here
_cairo_surface_is_quartz (const cairo_surface_t *surface);
References: https://bugs.freedesktop.org/show_bug.cgi?id=84569
Signed-off-by: Bryce Harrington <b.harrington@samsung.com>
|
| |
|
|
|
|
|
|
|
|
| |
This is a follow-up patch on top of 150c1e7044c57443d458e12bfc427d3a019cb60b
As discussed in the mailing list, http://lists.cairographics.org/archives/cairo/2014-September/025647.html,
check if the surfaces are of particular backend type or not, before proceeding further.
These changes are based on _cairo_surface_is_xlib() and _cairo_surface_is_image()
Signed-off-by: Ravi Nanjundappa <nravi.n@samsung.com>
|
| |
|
|
|
|
| |
Return an error surface instead.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=58061
|
| |
|
|
| |
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
| |
|
|
|
|
|
|
|
|
| |
quartz-image uses _cairo_surface_is_image(), which is now declared in
cairo-image-surface-inline.h.
Fixes:
cairo-quartz-image-surface.c: In function 'cairo_quartz_image_surface_create':
cairo-quartz-image-surface.c:312: error: implicit declaration of function '_cairo_surface_is_image'
cairo-quartz-image-surface.c:312: warning: nested extern declaration of '_cairo_surface_is_image'
|
| |
|
|
| |
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
| |
|
|
| |
Map allocates a surface. Symmetrically, unmap should destroy it.
|
| |
|
|
|
| |
This makes it easier to check that the funciton is returning the
correct type of surfaces.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
| |
The names of the function arguments in the function prototype and
in the description comment must match, otherwise gtk-doc is confused.
When the argument names differ between function prototype and
definition, use the names from the prototype.
Also add a missing colon.
Signed-off-by: Uli Schlachter <psychon@znc.in>
|
| |
|
|
| |
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
| |
|
|
|
|
|
| |
Add missing headers and fix some minor things (typos, missing
arguments, changed function name).
Map and unmap now rely on the generic path.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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. :)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
| |
83bfd85a1378e61b8bdc3f554f5e07900311f61f and
2458120dee350cd1b49f999f64b17a895a4b6607 did not update some backends
properly, breaking their compilation.
|
| |
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
| |
We never used the x,y portion of the extents so we might as well take it out.
|
| |
|
|
|
|
| |
Corporation"
From https://bugzilla.mozilla.org/show_bug.cgi?id=507387
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
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 function _cairo_image_surface_create_for_content does not exist.
The correct name of the function is instead _cairo_image_surface_create_with_content.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
▏
|
| |
|
|
|
|
|
|
| |
Adds an error code replacing CAIRO_STATUS_NO_MEMORY in one case where it
is not really appropriate. CAIRO_STATUS_INVALID_SIZE is used by several
backends that do not support image sizes beyond 2^15 pixels on each side.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
Instead of fixing the check in d36b02dc662e623bee58a69c32b149a242cbf52b, just
remove it. Conditionally compilation will keep cairo-quartz-image-surface.c
from being compiled in when it is not configured to be. Suggested by Behdad.
|
| |
|
|
|
|
| |
Fixes compilation by re-adding '#ifdef CAIRO_HAS_QUARTZ_IMAGE_SURFACE' which
was, I assume, unintentionally removed by
2cf4b3161c19b9b0349bd2aa94855fd0822968be.
|
| | |
|
| | |
|
| |
|
|
| |
Vlad, you need to stop throwing random OOM errors...
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
Creating a CGImage with interpolation set to FALSE means that
it will never be interpolated; otherwise the interoplation
is controlled by the destination context's interpolation
quality setting.
|
| | |
|
| | |
|
| |
|
