In the event of an empty bounded rectangle, the computation of the
unbounded - bounded rectangles leads to negative areas, integer overflow
and death.
[And similarly for the derived surfaces.]
Long ago when converting the pixel shader structs into macros and
reducing the code size by ~100k (the inlines were too depth for constant
propagation and CSE), I broke the encoding of negated channels. So
instead use a single bit to indicate a negation rather than 2s
complement (with sign extension into neighbouring channels, oops). The
disadvantage is that expressing the negated channel is a little more
ugly.
We were exposing the actual value of CAIRO_FORMAT_INVALID
through API functions already, so it makes sense to just
go ahead and put it in the cairo_format_t enum.
If a signal interrupts the SET_TILING ioctl, the tiling and stride
values are updated to reflect the current condition of the buffer, so we
need to restore those to the desired values before repeating the ioctl.
If the surface was written to using a fallback, and so is mapped, we
need to flush those modifications by relinquishing the map. So the next
time the application tries to write to the surface, those writes are
correctly serialised with our reads.
Check through error paths to catch a few more places where the mapped bo
may have been leaked, and add an assert to abort in case we do leak a
mapping.
As uploading to a tiled buffer is much slower than linear memory, don't
unless we expect to reuse the texture. This is not true for sub-image
clones, which are single shot affairs.
As proof-of-principle add the nearly working demonstrations of using DRM
to render directly with the GPU bypassing both RENDER and GL for
performance whilst preserving high quality rendering.
The basis behind developing these chip specific backends is that this is
the idealised interface that we desire for this chips, and so a target
for cairo-gl as we continue to develop both it and our GL stack.
Note that this backends do not yet fully pass the test suite, so only
use if you are brave and willing to help develop them further.
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.
As a simple step to ensure that we do not inadvertently modify (or at least
generate compiler warns if we try) user data, mark the incoming style
and matrices as constant.
Use the DRM interface to h/w accelerate composition on image surfaces.
The purpose of the backend is simply to explore what such a hardware
interface might look like and what benefits we might expect. The
use case that might justify writing such custom backends are embedded
devices running a drm compositor like wayland - which would, for example,
allow one to write applications that seamlessly integrated accelerated,
dynamic, high quality 2D graphics using Cairo with advanced interaction
(e.g. smooth animations in the UI) driven by a clutter framework...
In this first step we introduce the fundamental wrapping of GEM for intel
and radeon chipsets, and, for comparison, gallium. No acceleration, all
we do is use buffer objects (that is use the kernel memory manager) to
allocate images and simply use the fallback mechanism. This provides a
suitable base to start writing chip specific drivers.
