summaryrefslogtreecommitdiff
path: root/shared
diff options
context:
space:
mode:
authorDerek Foreman <derek.foreman@collabora.com>2022-02-09 12:38:20 -0600
committerDerek Foreman <derek.foreman@collabora.com>2023-02-01 07:27:05 -0600
commite1b4ad7d0bd6f3dbefd018549c8ba997d4cef034 (patch)
tree698dffc4d878355f95e5e4802be9af77a27ecb76 /shared
parentfe4d5711bf6d8e3dae9e850c418dcfbb9ec0df39 (diff)
downloadweston-e1b4ad7d0bd6f3dbefd018549c8ba997d4cef034.tar.gz
matrix: Introduce weston_coord
All through weston we have code that passes int x, y or float x, y or wl_fixed_t x, y pairs. These pairs are frequently converted to/from wl_fixed_t and other types. We also have struct vec2d and struct weston_geometry which also contain coordinate pairs. Let's create a family of coordinate vector structures for coordinate pairs and use it anywhere we sensibly can. This has a few benefits - it helps remove intermediate conversion between fixed/float/int types. It lets us roll the homogenous coordinate normalization bits into helper functions instead of needing them open coded throughout the source. Possibly most importantly, it also allows us to do some compile time validation of what coordinate space we're working in. Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Diffstat (limited to 'shared')
-rw-r--r--shared/matrix.c16
1 files changed, 16 insertions, 0 deletions
diff --git a/shared/matrix.c b/shared/matrix.c
index f41abe76..472f299a 100644
--- a/shared/matrix.c
+++ b/shared/matrix.c
@@ -126,6 +126,22 @@ weston_matrix_transform(const struct weston_matrix *matrix,
*v = t;
}
+WL_EXPORT struct weston_coord
+weston_matrix_transform_coord(const struct weston_matrix *matrix,
+ struct weston_coord c)
+{
+ struct weston_coord out;
+ struct weston_vector t = { { c.x, c.y, 0.0, 1.0 } };
+
+ weston_matrix_transform(matrix, &t);
+
+ assert(fabsf(t.f[3]) > 1e-6);
+
+ out.x = t.f[0] / t.f[3];
+ out.y = t.f[1] / t.f[3];
+ return out;
+}
+
static inline void
swap_rows(double *a, double *b)
{