| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
| |
Bounds are assumed to be normalized, and transforms
with negative scales or 3d rotations can make us get
negative sizes.
Fix by Benjamin Otte.
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
Some of the graphene_matrix_transform apis don't work
correctly with projective matrices, so add our own
variants.
|
| |
|
|
|
|
| |
Make the simple cases more explicit.
|
|
|
|
| |
We only use this in gsktransform.c
|
|
|
|
| |
This was found by running our testsuite under asan.
|
| |
|
|
|
|
| |
This has nothing to do with matrices.
|
| |
|
|
|
|
|
| |
This is handled with the is_identity() check as well but this way it's
much more obvious what's happening
|
|
|
|
| |
See attached tests
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
All angles are in the [0; 360[ range
|
|
|
|
|
| |
360deg should be expressed as 0deg and no angle should ever be
negative.
|
|
|
|
|
| |
Equivalent of gsk_transform_transform_bounds() and
graphene_matrix_transform_point() respectively.
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
If the epsilon we use there is too much, we can run into rendering
errors because the GPU will use the actual scale value.
|
|
|
|
| |
Make these two code paths look the same.
|
| |
|
|
|
|
|
| |
Otherwise we might end up with inaccuracies, e.g. when
gsk_transform_transform_bounds()'ing bounds.
|
|
|
|
| |
Make sure all angles are in the [0..365) range
|
|
|
|
| |
There is no @m.
|
|
|
|
| |
Fixes https://gitlab.gnome.org/GNOME/gtk/issues/2107
|
|
|
|
| |
Returning an extra ref will cause leaks later.
|
|
|
|
|
|
| |
E.g. anything involving a scale. This is important when e.g. scrolling
in the node list in the recorder, which scales every recorded node down
to fit in the list.
|
| |
|
|\
| |
| |
| |
| | |
Transform tests
See merge request GNOME/gtk!910
|
| |
| |
| |
| |
| | |
These need to print as "none", otherwise
the parser does not accept them.
|
| |
| |
| |
| | |
Fix up a variable name mismatch in GskTransform docs.
|
|/ |
|
|
|
|
|
| |
We often end up with e.g. a scale of 1 or a translation by 0/0. Ignore
those transforms since they don't do anything.
|
|
|
|
|
|
|
|
|
|
|
| |
If somebody does a transform like
scale(5) scale(10) translate(1,1) translate(5,0)
store it instead as
scale(50) translate(6,1)
This way, less memory is consumed and transforms are easier to read.
In particular, this simplifies the typical transforms we do in GTK,
which are just one translation after another.
|
|
|
|
|
| |
This happens if you apply a perspective transform and its inverse, which
is the negative version of the perspective.
|
|
|
|
| |
Add some missing symbols.
|
|
|
|
| |
Instead of accessing the matrix cells directly.
|
|
|
|
|
|
| |
Floating point values cannot ever be compared for equality. GLib has a
G_APPROX_VALUE macro that lets us compare two value within a provided
precision, so we should use that instead.
|
|
|
|
|
| |
Graphene has new API to check for equality, so we should use it instead
of doing a byte-by-byte comparison.
|
|
|
|
|
|
| |
Artisanal, homegrown, locally sourced, vegan reference counting has been
replaced by the appropriate API in GLib, which does small things like
saturation and type checking.
|
|
|
|
| |
It uses the new CSS parser.
|
|
|
|
|
|
|
|
|
| |
gsk/gskenums.h:181: Error: Gsk: multiple "@GSK_TRANSFORM_CATEGORY_2D" parameters for identifier "GskTransformCategory":
* @GSK_TRANSFORM_CATEGORY_2D: The matrix is a 2D matrix. This is equivalent
^
gsk/gsktransform.c:1342: Warning: Gsk: gsk_transform_to_2d: unknown parameter 'm' in documentation comment, should be 'self'
gsk/gsktransform.c:1368: Warning: Gsk: gsk_transform_to_2d: invalid return annotation
gsk/gsktransform.c:1461: Warning: Gsk: gsk_transform_to_translate: unknown parameter 'm' in documentation comment, should be 'self'
|
|
|
|
|
| |
This commit adds gsk_transform_perspective(), gtk_snapshot_perspective()
and support for perspective() in the CSS syntax.
|
|
|
|
| |
This is the optimization from bbd4e2f60d9e060fbe3b0c2dcebcd1d6b7335a2a
|
|
|
|
|
|
|
|
|
|
|
| |
Make the API expect a tranform of the proper category instead of
doing the check ourselves and returning TRUE/FALSE.
The benefit is that the mai use case is switch (transform->category)
statements and in those we know the category and don't need to check
TRUE/FALSE.
Using the wrong matrix will now cause a g_warning().
|
|
|
|
|
|
|
|
| |
... instead of computing it every time we need it.
This should be faster and we want to use it a lot more prominently.
Also, we have the struct memory available anyway.
|
|
|
|
|
|
| |
And use it.
And test it.
|