GCC 12.2 reports the following warning:
[3/16] Compiling C object util/cairo-script/libcairo-script-interpreter.so.2.11801.1.p/cairo-script-scanner.c.o
../util/cairo-script/cairo-script-scanner.c:1562:38: warning: implicit conversion from 'int' to 'float' changes value from 2147483647 to 2147483648 [-Wimplicit-const-int-float-conversion]
if (real >= INT32_MIN && real <= INT32_MAX && (int) real == real)
~~ ^~~~~~~~~
/usr/include/stdint.h:123:22: note: expanded from macro 'INT32_MAX'
^~~~~~~~~~
We should default on every platform we care about to hidden symbols, to
avoid leaking private symbols.
On Windows this is the default state of affairs with the MSVC toolchain;
with GCC and GCC-compatible toolchains, we need to opt into this
behaviour. Luckily for us, Cairo already has an annotation for public
symbols, so we can easily tweak it to include the visibility attribute.
When building ancillary libraries as part of the Cairo compilation on
Windows, we use a pre-processor symbol to ensure that we keep the
dllexport annotation. This avoids including the cairoint.h header file.
Fixes: #582
The original "slim" symbol rewriting was added without any shred of a
set of performance evaluation, and mostly copy-pasted from a very early
version of pixman. Pixman itself never used them, and most C
libraries—like GLib and GTK—have dropped similar mechanisms over the
past 15 years, as linkers have improved considerably in the meantime.
Modern linkers provide functionality to avoid intra-library PLT jump
through flags like `-Bsymbolic-functions`; we should use that, instead,
and keep the code base more maintainable and debuggable.
The GL support in Cairo has always been a prototype, and
nothing happened in the past 10+ years to make it work as
it was meant to.
GL support is not enabled by any downstream packagers of
Cairo, so nobody should notice its absence.
The rest of cairo (and therefore most external packages that depend
on cairo) doesn't make any use of liblzo.
Signed-off-by: Simon McVittie <smcv@debian.org>
This wasn't previously marked as private because it was initially
static inline, and only became extern later.
Fixes: 9ffbf63d "fix warning: inlining failed in call to '_csi_stack_push'"
Resolves: https://gitlab.freedesktop.org/cairo/cairo/-/issues/580
Signed-off-by: Simon McVittie <smcv@debian.org>
The FT change is because my MinGW build is using a more recent version
of FT.
Remove the disabled _cairo_win32_scaled_font_text_to_glyphs() code to
fix the defined but not used warning.
_cairo_win32_scaled_font_text_to_glyphs() was diabled in d9408041aa with
the comment:
"Currently disable the win32-font text_to_glyphs(), until that one
is updated. Or better yet, remove it and implement
ucs4_to_index(). It's the toy font API afterall."
_cairo_win32_scaled_font_ucs4_to_index() was added in d1c619bc7d.
On 64-bit windows, long is 32-bit. When compiling there are a large
number of warnings about mismatched sizes when casting long to/from a
pointer.
Use the (u)intptr_t type for any integer that will have a pointer stored
in it. Use a (u)intptr_t cast when integers are stored in pointers to
silence warnings.
Fixes#263
For example, to depend on cairo-script, inccairoscript was added to
"include_directories:" and libcairoscript was added to "link_with:".
This commit instead uses the libcairoscript_dep dependency everywhere.
Signed-off-by: Uli Schlachter <psychon@znc.in>
We *always* generate this file, and we depend on its existence.
The idea behind HAVE_CONFIG_H was being able to include random files
from different projects, back in a time where "libraries" were literally
just random files instead of actual shared objects.
Since we're not in the '80s any more, and our build system(s) define
HAVE_CONFIG_H *and* generate the config.h header file, we don't need a
conditional guard around its inclusion.
Precisely what Autotools does, instead of adding it as per-target C
argument.
Once we remove HAVE_CONFIG_H checks in every source file, we'll be able
to drop it.
Found via `codespell -i 3 -w -I ../cairo-word-whitelist.txt -L tim,ned,uint`
Follow up of 12cb59be7d
Reviewed-by: Bryce Harrington <bryce@bryceharrington.org>
IGT wants to add support for planes with a bit depth >10, which
requires a higher precision format than we have currently.
I'm using RGBA as format, because of its existence in OpenGL.
With the new formats we can directly convert our bytes to half float,
or multiply a colro vector with a matrix to go to the Y'CbCr colorspace.
This requires pixman 0.36.0, so bump the version requirement.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Bryce Harrington <bryce@bryceharrington.org>
csi-trace does not show help string correctly, due to a bug in its
command line argument parsing. strcmp returns 0 when there is an exact
match, which means it requires an inverted test.
Reviewed-by: Bryce Harrington <bryce@osg.samsung.com>
On AIX, the token jmpbuf is a pre-processor macro.
cairo-script-scanner.c includes a private struct with a member named
jmpbuf which gets renamed to __jmpbuf when AIX's sys/context.h has been
included.
While judicious ordering of includes might kludge around this problem
(by causing all references to .jmpbuf to become .__jmpbuf), it's better
to simply select a new name for the struct member that won't suffer the
collision.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=89339
Signed-off-by: Bryce Harrington <bryce@osg.samsung.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Use quoted includes rather than bracketed, to prefer linking to the
in-tree cairo in preference to the system cairo.
Signed-off-by: Bryce Harrington <bryce@osg.samsung.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Chris wrote all of the cairo script stuff. I'm making a guess about the
copyright date.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Bryce Harrington <bryce@osg.samsung.com>
Quells the following warning:
cairo-script-scanner.c: In function ‘_translate_string’:
cairo-script-scanner.c:1623:18: warning: comparison between signed and
unsigned integer expressions [-Wsign-compare]
if (buf_len <= 8 + 2*string->len) {
^
CSI_STATUS_SUCCESS is defined as equivalent to CAIRO_STATUS_SUCCESS.
We should prefer the former when comparing against csi_status_t
variables, else we'll get a warning:
cairo-script-interpreter.c:637:23: warning: comparison between
‘csi_status_t’ and ‘enum _cairo_status’ [-Wenum-compare]
Signed-off-by: Bryce Harrington <b.harrington@samsung.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
This quells the following warning:
warning: enumeration value ‘LZO’ not handled in switch [-Wswitch-enum]
The LZO enum value is defined and used elsewhere, even if lzo support
isn't available.
This situation might arise if cairo scripts were generated on one system
with lzo, and then replayed on a system without it. For now simply
error out if this occurs.
Signed-off-by: Bryce Harrington <b.harrington@samsung.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
But note we can only do the exchange if they do indeed match and
there are no other references (the objects are only on the stack).
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Try using the lighter-weight LZO decompressor in an effort to speed up
replays (at the cost of making the bound traces slightly larger).
Presuming that with the slight increase in file size (from -1% to +10%),
the file data remains in the readahead buffer cache, replays see a
performance improvement of between 5-10%.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The idiom (and expectation) for surface operators is that it leaves the
surface on the stack for the next operation. Also we need to hold onto a
surface reference for objects put onto the stack, yet for the
map-to-image return we did not own one.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If we fail to resolve a particular pattern, try removing a few features
from the pattern and see if we can resolve that fallback and continue on
with the trace with a close approximation.
This is then behaves very similar as if the pattern requested a specific
font that was not available on the system and so was substituted.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
We were calling the antialias close function from the unantialiased
paths - a function that operates on a completely different structure to
the one passed in.
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. :)
