You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
GTK uses graphene_rect_t for 2d bounding boxes in a number of places, but its representation as origin+size makes is somewhat unsuitable for that use. Issues:
due to floating point rounding, a a rect around p1, p2 may not actually contain p2
intersecting rects with empty interior (such as bounding boxes for axis-aligned line segments) returns FALSE
graphene_box_t seems to be made for bounding box uses, and uses a min-max representation internally, but it has that extra z. It would be nice to have a graphene_box2d_t
The text was updated successfully, but these errors were encountered:
The rect type was created as a description of a rectangle, with direct access to its fields mostly meant for ease of writing, just like we have separate 3D point and a vec3 types.
A 2D axis-aligned bounding box type is a perfectly fine addition; its implementation can probably be lifted from clutter_box_t, with the removal of the Z coordinate. You could even store the origin and anti-origin of the box as a packed SIMD type, since you have only four floats.
It gets a bit more hairy if you want direct access to its fields, so I guess the question is: do you expect to use it as you'd use graphene_box_t, or do you plan to access (x1, y1) and (x2, y2) directly?
GTK uses graphene_rect_t for 2d bounding boxes in a number of places, but its representation as origin+size makes is somewhat unsuitable for that use. Issues:
graphene_box_t seems to be made for bounding box uses, and uses a min-max representation internally, but it has that extra z. It would be nice to have a graphene_box2d_t
The text was updated successfully, but these errors were encountered: