Before this commit, calling cairo_device_finish() on a cairo-script
context did not actually do anything in the backend. Thus, it was
possible to continue emitting output on the script context even after it
was finished, which means that API user had no way of preventing
use-after-free bugs in their write callback. Bug 277 triggers this via
detaching a snapshot, but I guess one could also simply continue drawing
to a script surface.
This commit implements the finish function by closing the underlying
stream.
However, that was not enough to fix things. This commit also turns
writing into a stream into a no-op after the stream was closed.
I checked that the new test case actually fails before this commit and
is indeed fixed by it.
Fixes: https://gitlab.freedesktop.org/cairo/cairo/-/issues/277
Signed-off-by: Uli Schlachter <psychon@znc.in>
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.
