2023-07-08 14:15:22 +00:00
|
|
|
/*
|
|
|
|
* Copyright © 2020 Benjamin Otte
|
|
|
|
*
|
|
|
|
* This library is free software; you can redistribute it and/or
|
|
|
|
* modify it under the terms of the GNU Lesser General Public
|
|
|
|
* License as published by the Free Software Foundation; either
|
|
|
|
* version 2.1 of the License, or (at your option) any later version.
|
|
|
|
*
|
|
|
|
* This library is distributed in the hope that it will be useful,
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
|
|
|
|
* Lesser General Public License for more details.
|
|
|
|
*
|
|
|
|
* You should have received a copy of the GNU Lesser General Public
|
|
|
|
* License along with this library. If not, see <http://www.gnu.org/licenses/>.
|
|
|
|
*
|
|
|
|
* Authors: Benjamin Otte <otte@gnome.org>
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
|
|
#pragma once
|
|
|
|
|
|
|
|
#include "gskpath.h"
|
|
|
|
#include "gskpathbuilder.h"
|
|
|
|
|
|
|
|
G_BEGIN_DECLS
|
|
|
|
|
gskpathop: Introduce a type to represent an aligned graphene_point_t
When we allocate a graphene_point_t on the stack, there's no guarantee
that it will be aligned at an 8-byte boundary, which is an assumption
made by gsk_pathop_encode() (which wants to use the lowest 3 bits to
encode the operation). In the places where it matters, force the
points on the stack and embedded in structs to be nicely aligned.
By using a distinct type for this (a union with a suitable size and
alignment), we ensure that the compiler will warn or error whenever we
can't prove that a particular point is, in fact, suitably aligned.
We can go from a `GskAlignedPoint *` to a `graphene_point_t *`
(which is always valid, because the `GskAlignedPoint` is aligned)
via &aligned_points[0].pt, but we cannot go back the other way
(which is not always valid, because the `graphene_point_t` is not
necessarily aligned nicely) without a cast.
In practice, it seems that a graphene_point_t on x86_64 *is* usually
placed at an 8-byte boundary, but this is not the case on 32-bit
architectures or on s390x.
In many cases we can avoid needing an explicit reference to the more
complicated type by making use of a transparent union. There's already
at least one transparent union in GSK's public API, so it's presumably
portable enough to match GTK's requirements.
Increasing the alignment of GskAlignedPoint also requires adjusting how
a GskStandardContour is allocated and initialized. This data structure
allocates extra memory to hold an array of GskAlignedPoint outside the
bounds of the struct itself, and that array now needs to be aligned
suitably. Previously the array started with at next byte after the
flexible array of gskpathop, but the alignment of a gskpathop is only
4 bytes on 32-bit architectures, so depending on the number of gskpathop
in the trailing flexible array, that pointer might be an unsuitable
location to allocate a GskAlignedPoint.
Resolves: https://gitlab.gnome.org/GNOME/gtk/-/issues/6395
Signed-off-by: Simon McVittie <smcv@debian.org>
2024-07-28 13:42:00 +00:00
|
|
|
/* We assume that arrays of graphene_point_t are aligned on an 8-byte
|
|
|
|
* boundary, which means we can use the lowest 3 bits to represent up
|
|
|
|
* to 8 distinct path operations. */
|
|
|
|
#define GSK_PATHOP_OPERATION_MASK (0x7)
|
|
|
|
|
|
|
|
/* graphene_point_t is a struct containing two floats, so an array of
|
|
|
|
* graphene_point_t on the stack is not necessarily 8-byte aligned
|
|
|
|
* unless we force it to be.
|
|
|
|
*
|
|
|
|
* Using a union for this means the compiler will warn or error if we
|
|
|
|
* have not handled these correctly: for example we can go from a
|
|
|
|
* GskAlignedPoint * to a graphene_point_t * (which is always OK) with:
|
|
|
|
*
|
|
|
|
* GskAlignedPoint *gap = ...;
|
|
|
|
* graphene_point_t *gpt;
|
|
|
|
* gpt = &gap[0].pt;
|
|
|
|
*
|
|
|
|
* but going back the other way is not possible without a cast or a
|
|
|
|
* compiler warning. */
|
|
|
|
typedef union
|
|
|
|
{
|
|
|
|
graphene_point_t pt;
|
|
|
|
|
|
|
|
/* On many platforms this will be enough to force the correct alignment. */
|
|
|
|
guint64 alignment;
|
|
|
|
|
|
|
|
/* Unfortunately not all platforms require guint64 to be naturally-aligned
|
|
|
|
* (for example on i386, only 4-byte alignment is required) so we have to
|
|
|
|
* try harder. */
|
|
|
|
#ifdef __GNUC__
|
|
|
|
__attribute__((aligned(8))) guint64 really_aligned;
|
|
|
|
#elif defined(_MSC_VER)
|
|
|
|
__declspec(align(8)) guint64 really_aligned;
|
|
|
|
#endif
|
|
|
|
} GskAlignedPoint;
|
|
|
|
|
|
|
|
G_STATIC_ASSERT (sizeof (GskAlignedPoint) == sizeof (graphene_point_t));
|
|
|
|
G_STATIC_ASSERT (G_ALIGNOF (GskAlignedPoint) >= GSK_PATHOP_OPERATION_MASK + 1);
|
|
|
|
|
2023-07-08 14:15:22 +00:00
|
|
|
typedef gpointer gskpathop;
|
|
|
|
|
|
|
|
static inline
|
|
|
|
gskpathop gsk_pathop_encode (GskPathOperation op,
|
gskpathop: Introduce a type to represent an aligned graphene_point_t
When we allocate a graphene_point_t on the stack, there's no guarantee
that it will be aligned at an 8-byte boundary, which is an assumption
made by gsk_pathop_encode() (which wants to use the lowest 3 bits to
encode the operation). In the places where it matters, force the
points on the stack and embedded in structs to be nicely aligned.
By using a distinct type for this (a union with a suitable size and
alignment), we ensure that the compiler will warn or error whenever we
can't prove that a particular point is, in fact, suitably aligned.
We can go from a `GskAlignedPoint *` to a `graphene_point_t *`
(which is always valid, because the `GskAlignedPoint` is aligned)
via &aligned_points[0].pt, but we cannot go back the other way
(which is not always valid, because the `graphene_point_t` is not
necessarily aligned nicely) without a cast.
In practice, it seems that a graphene_point_t on x86_64 *is* usually
placed at an 8-byte boundary, but this is not the case on 32-bit
architectures or on s390x.
In many cases we can avoid needing an explicit reference to the more
complicated type by making use of a transparent union. There's already
at least one transparent union in GSK's public API, so it's presumably
portable enough to match GTK's requirements.
Increasing the alignment of GskAlignedPoint also requires adjusting how
a GskStandardContour is allocated and initialized. This data structure
allocates extra memory to hold an array of GskAlignedPoint outside the
bounds of the struct itself, and that array now needs to be aligned
suitably. Previously the array started with at next byte after the
flexible array of gskpathop, but the alignment of a gskpathop is only
4 bytes on 32-bit architectures, so depending on the number of gskpathop
in the trailing flexible array, that pointer might be an unsuitable
location to allocate a GskAlignedPoint.
Resolves: https://gitlab.gnome.org/GNOME/gtk/-/issues/6395
Signed-off-by: Simon McVittie <smcv@debian.org>
2024-07-28 13:42:00 +00:00
|
|
|
const GskAlignedPoint *pts);
|
|
|
|
static inline
|
|
|
|
const GskAlignedPoint *gsk_pathop_aligned_points (gskpathop pop);
|
2023-07-08 14:15:22 +00:00
|
|
|
static inline
|
|
|
|
const graphene_point_t *gsk_pathop_points (gskpathop pop);
|
|
|
|
static inline
|
|
|
|
GskPathOperation gsk_pathop_op (gskpathop pop);
|
|
|
|
|
|
|
|
static inline
|
|
|
|
gboolean gsk_pathop_foreach (gskpathop pop,
|
|
|
|
GskPathForeachFunc func,
|
|
|
|
gpointer user_data);
|
|
|
|
|
|
|
|
/* included inline so tests can use them */
|
|
|
|
static inline
|
|
|
|
void gsk_path_builder_pathop_to (GskPathBuilder *builder,
|
|
|
|
gskpathop op);
|
|
|
|
static inline
|
|
|
|
void gsk_path_builder_pathop_reverse_to (GskPathBuilder *builder,
|
|
|
|
gskpathop op);
|
|
|
|
|
|
|
|
/* IMPLEMENTATION */
|
|
|
|
|
2023-08-25 02:16:08 +00:00
|
|
|
/* Note:
|
|
|
|
*
|
|
|
|
* The weight of conics is encoded as p[2].x, and the endpoint is p[3].
|
|
|
|
* This is important, since contours store the points of adjacent
|
|
|
|
* operations overlapping, so we can't put the weight at the end.
|
|
|
|
*/
|
|
|
|
|
2023-07-08 14:15:22 +00:00
|
|
|
static inline gskpathop
|
|
|
|
gsk_pathop_encode (GskPathOperation op,
|
gskpathop: Introduce a type to represent an aligned graphene_point_t
When we allocate a graphene_point_t on the stack, there's no guarantee
that it will be aligned at an 8-byte boundary, which is an assumption
made by gsk_pathop_encode() (which wants to use the lowest 3 bits to
encode the operation). In the places where it matters, force the
points on the stack and embedded in structs to be nicely aligned.
By using a distinct type for this (a union with a suitable size and
alignment), we ensure that the compiler will warn or error whenever we
can't prove that a particular point is, in fact, suitably aligned.
We can go from a `GskAlignedPoint *` to a `graphene_point_t *`
(which is always valid, because the `GskAlignedPoint` is aligned)
via &aligned_points[0].pt, but we cannot go back the other way
(which is not always valid, because the `graphene_point_t` is not
necessarily aligned nicely) without a cast.
In practice, it seems that a graphene_point_t on x86_64 *is* usually
placed at an 8-byte boundary, but this is not the case on 32-bit
architectures or on s390x.
In many cases we can avoid needing an explicit reference to the more
complicated type by making use of a transparent union. There's already
at least one transparent union in GSK's public API, so it's presumably
portable enough to match GTK's requirements.
Increasing the alignment of GskAlignedPoint also requires adjusting how
a GskStandardContour is allocated and initialized. This data structure
allocates extra memory to hold an array of GskAlignedPoint outside the
bounds of the struct itself, and that array now needs to be aligned
suitably. Previously the array started with at next byte after the
flexible array of gskpathop, but the alignment of a gskpathop is only
4 bytes on 32-bit architectures, so depending on the number of gskpathop
in the trailing flexible array, that pointer might be an unsuitable
location to allocate a GskAlignedPoint.
Resolves: https://gitlab.gnome.org/GNOME/gtk/-/issues/6395
Signed-off-by: Simon McVittie <smcv@debian.org>
2024-07-28 13:42:00 +00:00
|
|
|
const GskAlignedPoint *pts)
|
2023-07-08 14:15:22 +00:00
|
|
|
{
|
|
|
|
/* g_assert (op & GSK_PATHOP_OPERATION_MASK == op); */
|
|
|
|
g_assert ((GPOINTER_TO_SIZE (pts) & GSK_PATHOP_OPERATION_MASK) == 0);
|
|
|
|
|
|
|
|
return GSIZE_TO_POINTER (GPOINTER_TO_SIZE (pts) | op);
|
|
|
|
}
|
|
|
|
|
gskpathop: Introduce a type to represent an aligned graphene_point_t
When we allocate a graphene_point_t on the stack, there's no guarantee
that it will be aligned at an 8-byte boundary, which is an assumption
made by gsk_pathop_encode() (which wants to use the lowest 3 bits to
encode the operation). In the places where it matters, force the
points on the stack and embedded in structs to be nicely aligned.
By using a distinct type for this (a union with a suitable size and
alignment), we ensure that the compiler will warn or error whenever we
can't prove that a particular point is, in fact, suitably aligned.
We can go from a `GskAlignedPoint *` to a `graphene_point_t *`
(which is always valid, because the `GskAlignedPoint` is aligned)
via &aligned_points[0].pt, but we cannot go back the other way
(which is not always valid, because the `graphene_point_t` is not
necessarily aligned nicely) without a cast.
In practice, it seems that a graphene_point_t on x86_64 *is* usually
placed at an 8-byte boundary, but this is not the case on 32-bit
architectures or on s390x.
In many cases we can avoid needing an explicit reference to the more
complicated type by making use of a transparent union. There's already
at least one transparent union in GSK's public API, so it's presumably
portable enough to match GTK's requirements.
Increasing the alignment of GskAlignedPoint also requires adjusting how
a GskStandardContour is allocated and initialized. This data structure
allocates extra memory to hold an array of GskAlignedPoint outside the
bounds of the struct itself, and that array now needs to be aligned
suitably. Previously the array started with at next byte after the
flexible array of gskpathop, but the alignment of a gskpathop is only
4 bytes on 32-bit architectures, so depending on the number of gskpathop
in the trailing flexible array, that pointer might be an unsuitable
location to allocate a GskAlignedPoint.
Resolves: https://gitlab.gnome.org/GNOME/gtk/-/issues/6395
Signed-off-by: Simon McVittie <smcv@debian.org>
2024-07-28 13:42:00 +00:00
|
|
|
static inline const GskAlignedPoint *
|
|
|
|
gsk_pathop_aligned_points (gskpathop pop)
|
|
|
|
{
|
|
|
|
return GSIZE_TO_POINTER (GPOINTER_TO_SIZE (pop) & ~GSK_PATHOP_OPERATION_MASK);
|
|
|
|
}
|
|
|
|
|
2023-07-08 14:15:22 +00:00
|
|
|
static inline const graphene_point_t *
|
|
|
|
gsk_pathop_points (gskpathop pop)
|
|
|
|
{
|
gskpathop: Introduce a type to represent an aligned graphene_point_t
When we allocate a graphene_point_t on the stack, there's no guarantee
that it will be aligned at an 8-byte boundary, which is an assumption
made by gsk_pathop_encode() (which wants to use the lowest 3 bits to
encode the operation). In the places where it matters, force the
points on the stack and embedded in structs to be nicely aligned.
By using a distinct type for this (a union with a suitable size and
alignment), we ensure that the compiler will warn or error whenever we
can't prove that a particular point is, in fact, suitably aligned.
We can go from a `GskAlignedPoint *` to a `graphene_point_t *`
(which is always valid, because the `GskAlignedPoint` is aligned)
via &aligned_points[0].pt, but we cannot go back the other way
(which is not always valid, because the `graphene_point_t` is not
necessarily aligned nicely) without a cast.
In practice, it seems that a graphene_point_t on x86_64 *is* usually
placed at an 8-byte boundary, but this is not the case on 32-bit
architectures or on s390x.
In many cases we can avoid needing an explicit reference to the more
complicated type by making use of a transparent union. There's already
at least one transparent union in GSK's public API, so it's presumably
portable enough to match GTK's requirements.
Increasing the alignment of GskAlignedPoint also requires adjusting how
a GskStandardContour is allocated and initialized. This data structure
allocates extra memory to hold an array of GskAlignedPoint outside the
bounds of the struct itself, and that array now needs to be aligned
suitably. Previously the array started with at next byte after the
flexible array of gskpathop, but the alignment of a gskpathop is only
4 bytes on 32-bit architectures, so depending on the number of gskpathop
in the trailing flexible array, that pointer might be an unsuitable
location to allocate a GskAlignedPoint.
Resolves: https://gitlab.gnome.org/GNOME/gtk/-/issues/6395
Signed-off-by: Simon McVittie <smcv@debian.org>
2024-07-28 13:42:00 +00:00
|
|
|
return &(gsk_pathop_aligned_points (pop)->pt);
|
2023-07-08 14:15:22 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static inline
|
|
|
|
GskPathOperation gsk_pathop_op (gskpathop pop)
|
|
|
|
{
|
|
|
|
return GPOINTER_TO_SIZE (pop) & GSK_PATHOP_OPERATION_MASK;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline gboolean
|
|
|
|
gsk_pathop_foreach (gskpathop pop,
|
|
|
|
GskPathForeachFunc func,
|
|
|
|
gpointer user_data)
|
|
|
|
{
|
|
|
|
switch (gsk_pathop_op (pop))
|
|
|
|
{
|
|
|
|
case GSK_PATH_MOVE:
|
2023-08-25 02:16:08 +00:00
|
|
|
return func (gsk_pathop_op (pop), gsk_pathop_points (pop), 1, 0, user_data);
|
2023-07-08 14:15:22 +00:00
|
|
|
|
|
|
|
case GSK_PATH_CLOSE:
|
|
|
|
case GSK_PATH_LINE:
|
2023-08-25 02:16:08 +00:00
|
|
|
return func (gsk_pathop_op (pop), gsk_pathop_points (pop), 2, 0, user_data);
|
2023-07-08 14:15:22 +00:00
|
|
|
|
|
|
|
case GSK_PATH_QUAD:
|
2023-08-25 02:16:08 +00:00
|
|
|
return func (gsk_pathop_op (pop), gsk_pathop_points (pop), 3, 0, user_data);
|
2023-07-08 14:15:22 +00:00
|
|
|
|
|
|
|
case GSK_PATH_CUBIC:
|
2023-08-25 02:16:08 +00:00
|
|
|
return func (gsk_pathop_op (pop), gsk_pathop_points (pop), 4, 0, user_data);
|
2023-07-08 14:15:22 +00:00
|
|
|
|
2023-08-25 02:16:08 +00:00
|
|
|
case GSK_PATH_CONIC:
|
|
|
|
{
|
|
|
|
const graphene_point_t *pts = gsk_pathop_points (pop);
|
|
|
|
return func (gsk_pathop_op (pop), (graphene_point_t[3]) { pts[0], pts[1], pts[3] }, 3, pts[2].x, user_data);
|
|
|
|
}
|
2023-08-18 17:32:37 +00:00
|
|
|
|
2023-07-08 14:15:22 +00:00
|
|
|
default:
|
|
|
|
g_assert_not_reached ();
|
|
|
|
return TRUE;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void
|
|
|
|
gsk_path_builder_pathop_to (GskPathBuilder *builder,
|
|
|
|
gskpathop op)
|
|
|
|
{
|
|
|
|
const graphene_point_t *pts = gsk_pathop_points (op);
|
|
|
|
|
|
|
|
switch (gsk_pathop_op (op))
|
|
|
|
{
|
|
|
|
case GSK_PATH_MOVE:
|
|
|
|
gsk_path_builder_move_to (builder, pts[0].x, pts[0].y);
|
|
|
|
break;
|
|
|
|
|
|
|
|
case GSK_PATH_CLOSE:
|
|
|
|
gsk_path_builder_close (builder);
|
|
|
|
break;
|
|
|
|
|
|
|
|
case GSK_PATH_LINE:
|
|
|
|
gsk_path_builder_line_to (builder, pts[1].x, pts[1].y);
|
|
|
|
break;
|
|
|
|
|
|
|
|
case GSK_PATH_QUAD:
|
|
|
|
gsk_path_builder_quad_to (builder, pts[1].x, pts[1].y, pts[2].x, pts[2].y);
|
|
|
|
break;
|
|
|
|
|
|
|
|
case GSK_PATH_CUBIC:
|
|
|
|
gsk_path_builder_cubic_to (builder, pts[1].x, pts[1].y, pts[2].x, pts[2].y, pts[3].x, pts[3].y);
|
|
|
|
break;
|
|
|
|
|
2023-08-25 02:16:08 +00:00
|
|
|
case GSK_PATH_CONIC:
|
|
|
|
gsk_path_builder_conic_to (builder, pts[1].x, pts[1].y, pts[3].x, pts[3].y, pts[2].x);
|
2023-08-18 17:32:37 +00:00
|
|
|
break;
|
|
|
|
|
2023-07-08 14:15:22 +00:00
|
|
|
default:
|
|
|
|
g_assert_not_reached ();
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void
|
|
|
|
gsk_path_builder_pathop_reverse_to (GskPathBuilder *builder,
|
|
|
|
gskpathop op)
|
|
|
|
{
|
|
|
|
const graphene_point_t *pts = gsk_pathop_points (op);
|
|
|
|
|
|
|
|
switch (gsk_pathop_op (op))
|
|
|
|
{
|
|
|
|
case GSK_PATH_MOVE:
|
|
|
|
gsk_path_builder_move_to (builder, pts[0].x, pts[0].y);
|
|
|
|
break;
|
|
|
|
|
|
|
|
case GSK_PATH_CLOSE:
|
|
|
|
gsk_path_builder_line_to (builder, pts[0].x, pts[0].y);
|
|
|
|
break;
|
|
|
|
|
|
|
|
case GSK_PATH_LINE:
|
|
|
|
gsk_path_builder_line_to (builder, pts[1].x, pts[1].y);
|
|
|
|
break;
|
|
|
|
|
|
|
|
case GSK_PATH_QUAD:
|
|
|
|
gsk_path_builder_quad_to (builder, pts[1].x, pts[1].y, pts[0].x, pts[0].y);
|
|
|
|
break;
|
|
|
|
|
|
|
|
case GSK_PATH_CUBIC:
|
|
|
|
gsk_path_builder_cubic_to (builder, pts[2].x, pts[2].y, pts[1].x, pts[1].y, pts[0].x, pts[0].y);
|
|
|
|
break;
|
|
|
|
|
2023-08-25 02:16:08 +00:00
|
|
|
case GSK_PATH_CONIC:
|
|
|
|
gsk_path_builder_conic_to (builder, pts[1].x, pts[1].y, pts[0].x, pts[0].y, pts[2].x);
|
2023-08-18 17:32:37 +00:00
|
|
|
break;
|
|
|
|
|
2023-07-08 14:15:22 +00:00
|
|
|
default:
|
|
|
|
g_assert_not_reached ();
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
G_END_DECLS
|