The CI runners for Windows are currently timing out on the fd.o
infrastructure. The issue is being worked on, but we should avoid
blocking our entire CI pipeline until it's fixed, as it sounds it is
going to take a while.
Nobody cares about BeOS in 2022, and it cannot be built with Meson anyway.
Removing the BeOS backend also allows us to drop the dependency on a C++
compiler and simplify the Autotools build considerably by removing all
the extra CXX targets.
CGContextDrawTiledImage turned up as a significant time-user while
profiling a benchmark created to evaluate
https://gitlab.gnome.org/GNOME/gtk/-/issues/3714. Without this commit
the benchmark is able to perform a mean frame rate of 2.19 frames per
second with a standard deviation of 0.09; with the commit the mean frame
rate is 2.37 fps, s.d. 0.30, both over 15 10-second samples. Student's
t-test reports a 9.8% likelyhood that the two represent the same
distribution.
Motivation: Avoid need to recreate CGImages for unchanged surfaces,
an expensive operation, while ensuring that the CGImages are properly
freed and new ones created when the surface does change.
Thanks to Uli Schlacter for suggestion and coding guidance.
In a couple of instances, code is present where two numbers are being
multiplied in a type like unsigned int, but immediately being casted
to a wider type like size_t.
This means, although the result can be any size_t value, the
multiplication can potentially overflow before it's used because
unsigned int has a smaller range of values.
In another more niche case, I also cast to size_t before multiplying
a signed integer, since the result is immediately used as an argument
to memcpy, which would give memory corruption if the value was negative
anyway.
The documentation for cairo_font_options_status says it can return
either CAIRO_STATUS_SUCCESS or CAIRO_STATUS_NO_MEMORY, but the
implementation can also return CAIRO_STATUS_NULL_POINTER, which wasn't
mentioned.
In some places, there were int variables being compared to unsigned
ints when they would never take a negative value, exposing some edge
cases that didn't need to be there.
When rendering clusters that have colored and non-colored
glyphs, we were falling back to using show_text_glyphs,
rendering all glyphs in the cluster without color.
Instead, make composite_one_color_glyph smart enough
to handle non-color glyphs, and only skip clusters
that are entirely non-color.
Testcase: hb-view AmiriQuranColored.otf -u 627,64e
When the run contains a mix of color and non-color
glyphs, composite_color_glyphs returns the non-color
glyphs unhandled in the same array. In the rtl case,
the glyphs are processed from the end and the unhandled
glyphs are accumulated at the end as well, and we
need to move them to the beginning of the array before
we return. Add the missing memmove call to do that.
Fixes: #533
Symbols from cairo-tag-stack.c are used by cairo-tag-attributes.c, so
this should be in the same list of sources as that. Fixes this build
error:
```
/usr/bin/ld: src/libcairo.so.2.11705.0.p/cairo-tag-attributes.c.o: in function `parse_array':
/path/to/cairo/_build/../src/cairo-tag-attributes.c:347: undefined reference to `_cairo_tag_error'
/usr/bin/ld: src/libcairo.so.2.11705.0.p/cairo-tag-attributes.c.o: in function `parse_name':
/path/to/cairo/cairo/_build/../src/cairo-tag-attributes.c:359: undefined reference to `_cairo_tag_error'
/usr/bin/ld: src/libcairo.so.2.11705.0.p/cairo-tag-attributes.c.o: in function `parse_attributes':
/path/to/cairo/cairo/_build/../src/cairo-tag-attributes.c:410: undefined reference to `_cairo_tag_error'
/usr/bin/ld: /path/to/cairo/cairo/_build/../src/cairo-tag-attributes.c:431: undefined reference to `_cairo_tag_error'
/usr/bin/ld: /path/to/cairo/cairo/_build/../src/cairo-tag-attributes.c:441: undefined reference to `_cairo_tag_error'
/usr/bin/ld: src/libcairo.so.2.11705.0.p/cairo-tag-attributes.c.o:/path/to/cairo/cairo/_build/../src/cairo-tag-attributes.c:455: more undefined references to `_cairo_tag_error' follow
/usr/bin/ld: src/libcairo.so.2.11705.0: hidden symbol `_cairo_tag_error' isn't defined
```
