The following Python script was used to compute "Since: 1.X" tags,
based on the first version where a symbol became officially supported.
This script requires a concatenation of the the cairo public headers
for the officially supported beckends to be available as
"../../includes/1.X.0.h".
from sys import argv
import re
syms = {}
def stripcomments(text):
def replacer(match):
s = match.group(0)
if s.startswith('/'):
return ""
else:
return s
pattern = re.compile(
r'//.*?$|/\*.*?\*/|\'(?:\\.|[^\\\'])*\'|"(?:\\.|[^\\"])*"',
re.DOTALL | re.MULTILINE
)
return re.sub(pattern, replacer, text)
for minor in range(12,-2,-2):
version = "1.%d" % minor
names = re.split('([A-Za-z0-9_]+)', stripcomments(open("../../includes/%s.0.h" % version).read()))
for s in names: syms[s] = version
for filename in argv[1:]:
is_public = False
lines = open(filename, "r").read().split("\n")
newlines = []
for i in range(len(lines)):
if lines[i] == "/**":
last_sym = lines[i+1][2:].strip().replace(":", "")
is_public = last_sym.lower().startswith("cairo")
elif is_public and lines[i] == " **/":
if last_sym in syms:
v = syms[last_sym]
if re.search("Since", newlines[-1]): newlines = newlines[:-1]
if newlines[-1].strip() != "*": newlines.append(" *")
newlines.append(" * Since: %s" % v)
else:
print "%s (%d): Cannot determine the version in which '%s' was introduced" % (filename, i, last_sym)
newlines.append(lines[i])
out = open(filename, "w")
out.write("\n".join(newlines))
out.close()
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.
For a foreign drawable, we have to assume to that is dirty upon creation
or otherwise we fail to read back the correct pixel data when copying to
an image.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If we need to fallback and perform a copy first to a pixmap for a
partially unviewable Window, we need to copy its inferiors as well.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The only reliable method would be to query the xserver for the
matching bpp for a particular depth. In the absence of such information,
simply chose the next higher power-of-two(depth).
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. :)
The existing API only described the method to be used for performing
rasterisation and unlike other API provided no opportunity for the user
to give a hint as to how to trade off performance against speed. So in
order to no be overly prescriptive, we extend the NONE/GRAY/SUBPIXEL
methods with FAST/GOOD/BEST hints and leave the backend to decide how
best to achieve those goals.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Broken (never set!) since the clipping overhaul. We could emulate the
xcb code to avoid setting it unnecessarily...
Fixes partial-clip-test.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This patch has been generated by the following Coccinelle semantic patch:
// Remove useless checks for NULL before freeing
//
// free (NULL) is a no-op, so there is no need to avoid it
@@
expression E;
@@
+ free (E);
+ E = NULL;
- if (unlikely (E != NULL)) {
- free(E);
(
- E = NULL;
|
- E = 0;
)
...
- }
@@
expression E;
@@
+ free (E);
- if (unlikely (E != NULL)) {
- free (E);
- }
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>
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>
In order to defer the pixel conversion till as late in the pipeline as
possible, we want to try and preserve the pixman image format whilst
uploading the pixel data. To do this, we want to create an XRender
surface with a matching PictFormat to the source image. Then we need to
make sure we take the quick path through _draw_image_surface for none
and direct conversions.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This adds checks for negative sizes in cairo_surface_create_similar() and for
non-positive sizes in all public surface-creation functions in the xcb and xlib
backends.
X11 doesn't allow 0 as width/height, so if anyone claims to have a drawable of
that size, he can't be right. However, cairo allows such sizes which is why
create_similar doesn't reject 0.
Signed-off-by: Uli Schlachter <psychon@znc.in>
45665c0d48 breaks the build of
cairo-xlib-xcb because it does not disable the compilation of
cairo-xlib implementation files when cairo-xlib-xcb is enable. This
results in collisions when linking.
Reported-by: James Cloos <cloos@jhcloos.com>
Introduce cairo_xlib_device_debug_set_precision() to override the
automatic selection of rendering precision and force the Xorg/DDX to
strictly adhere to the precise rendering mode of the Render
specification. This allows us to test drivers without worrying, too
much, about minor discrepancies in antialiasing.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The RENDER specification requires radial gradients to have the first
circle completely inside the second one, but the error is not actually
generated.
The implementation produces the expected results if either circle
contains the other one, so only fall back in these cases.
The RENDER specification does not specify the constraints on the
gradient stops, but its implementation returns an error if less than 2
stops are used.
Xlib and XCB can work around this because gradients with just one stop
are by-definition the same as gradients with that stop repeated twice.
Fixes radial-gradient-one-stop.
The same code was duplicated (incorrectly and with some minor
differences) in pattern, image, xlib and xcb.
_cairo_gradient_pattern_max_val() abstracts that code in a function
that can be used whenever a gradients extremes need to be rescaled to
fit within a given range.
Fixes huge-linear, huge-radial.
Fixes part of https://bugs.freedesktop.org/show_bug.cgi?id=32215
Xlib, XCB and image use the same code to convert a cairo_matrix_t to a
backend-specific transform.
The code did not handle correctly some matrices, thus a new function
that performs the conversion in a more generic way was added and used
in the backends instead of fixing the repeated code.
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.
Remove the hack of using the xlib surface to do glyph rendering and use
the new interface introduced with Qt4.7, or else fallback to image
rendering with freetype.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
[2 files changed, 35 insertions(+), 140 deletions(-) \o/]
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).
Under the restrictive conditions where we are doing an untransformed
contained upload of an image into a matching surface, perform it in
place. The drivers will attempt to stream such uploads efficiently, far
more so than our code.
Render supports two modes of precision when rendering trapezoids.
Precise specifies points sampling on a 15x17 grid, ala pixman. Imprecise
allows the driver more freedom in the methods used, which may be more
amenable to acceleration. Choose to use the imprecise mode by default,
but still allow users to force the more rigidly specified precision by
changing the antialias mode.
Not only is this useful for users to know which Visual matches any
particular Cairo surface, it should also close a few obscure bugs of not
converting images correctly on upload.
Fixes:
Bug 28492 - cairo_xlib_surface_create_with_xrender_format does not
create visual for resulting surface
https://bugs.freedesktop.org/show_bug.cgi?id=28492
Mozilla Bug 567065 - Try to create offscreen Xlib surface from existing
visual if possible
https://bugzilla.mozilla.org/show_bug.cgi?id=567065
Mozilla Bug 445250 - cairo_draw_with_xlib should provide a non-NULL visual
to callback
https://bugzilla.mozilla.org/show_bug.cgi?id=445250
Reported-by: Oleg Romashin <romaxa@gmail.com>
