This category does a finer-grained categorization than
GskTransformCategory, but it is deliberatedly made to allow
easy backwards compatibility.
The reason for the categories is that they fit our renderers more
fine.
In particular, it allows implementing wl_output_transform support more
efficiently, thereby allowing rendering buffers the right way for
rotated phone screens or monitors.
Since GskTransform is immutable, a lot of the documented "methods" are
more like "functions", in the sense that they don't keep the instance
alive but rather consume it.
This is annotated with `(transfer full)`, but since these functions are
listed as methods, their first argument is not shown.
Instead, let's add a line to the docs of each consuming function that
clarifies this behavior.
...and not around the center of the render node, as one could expect
given that the render node syntax for rotation, transform: rotate(90);,
happens to match the CSS syntax for the same thing, and CSS does rotate
around the center by default.
Signed-off-by: Sergey Bugaev <bugaevc@gmail.com>
Various transforms are normalized with their next transform, and if they
end up being the identity transform will return NULL.
For example a translation by (x,y,z) and followed by (-x,-y,-z) will
result in NULL.
Remove a boatload of "or %NULL" from nullable parameters
and return values. gi-docgen generates suitable text from
the annotation that we don't need to duplicate.
This adds a few missing nullable annotations too.
This is a projecting version of the corresponding
graphene api. While we are at it, rewrite
gsk_matrix_transform_bounds() to use
gsk_matrix_transform_rect().
Replace our uses of graphene_matrix_transform_point,
_point3d and _bounds by our own versions that handle
projective transforms correctly.
This fixes render node bounds being incorrect for widgets
involving projective transforms (e.g. testrevealer swing
transformations), and also fixes picking on such widgets.
Transforming identity by an other transform does not mean we need to
painstakingly apply the individual steps of other to construct a new
transform, it means we can just return other.
Or in math terms:
I * B = B
so just return B.
I was getting assertions that normalize_angle() failed the
result < 260 check. Doing some research on this it turns out
to be a precision issue. If the incomming angle is very slightly
below zero, then adding 360 to it may end up with exactly 360.
I simplified the code a bit to avoid division and rounding, because in
practice most angles will be "just outside" the 0-360 degree anyway.
And i also added a workaround for the "result is 360" case by just
setting it to 0.
sincosf() is really a GCC-specific function that may more may not be
supported on non-GCC compilers, so we want to check for it, otherwise we
use a fallback implementation, not unlike the one in
demos/gtk-demo/gtkgears.c.
