2d bounding boxes
matthiasclasen opened this issue · 3 comments
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 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?
I have no deep thoughts on that. The main operations I foresee on a bounding box type are:
- containment/overlap checks (for points and rects)
- unions