Geometry types

[dhardy]

Currently KAS uses ad-hoc geometric types, because this was the fastest way to get started. There are several disadvantages however (frequent API extensions when required, some lack of uniformity of design).

There are already several vector / linear algebra libraries; one of these may suffice (although most include significantly more functionality than we require):

• vek focuses on 2D and 3D geometry and graphics primitives and may be a good fit, and is templated over numeric types
• euclid is used by Servo and Lyon with a design focus around 2D graphics (also some 3D), templated over numeric types and units
• ultraviolet has a nice clean design (not templated) but is mostly aimed at 3D graphics (especially ray tracing)
• cgmath is another 3D-graphics oriented lib, templated, and largely concerning vectors and matrices

Both Vek and Euclid may be viable choices. Euclid may make for easier interoperation with Lyon for an embedded canvas (as Iced now supports).

Coordinate system

Currently we place the origin at the top-left. Since version 0.5 WebGPU, now places the origin at the bottom-left. Should we also flip the Y axis?

[dhardy]

Note: 32-bit integers are more than enough for pixel sizes on any screen imaginable, yet one can still hit their limits: calculating size requirements for very large lazily-instantiated lists of items (as in filter-list example with somewhere between 31M and 310M entries).

[dhardy]

Another option:

• glam is another library focussed on computer graphics, and is used by bevy

However, the Size, Coord and Rect types now have exactly the desired functionality, and augmenting this where necessary is easy, thus the original motivation is lacking. Further, it is easy to add conversion routines on our own types (e.g. from winit's PhysicalPosition), thus continuing to use our own types appears the best option. For Size, Coord and Rect, Euclid is the only real alternative, and it is considerably more complex than required.

There remains a question of whether to rename the above (Coord → Point or Position and maybe Size → Extent or Vector), but motivation is limited (mostly that Point is widely used).

For our Vec2, Vec3, DVec2 and Quad types, any of the CG-focussed libraries would be a viable alternative, though we lose the option to convert kas_text::Vec2 via .into(), inherit a lot of unneeded functionality, and may have to define Quad ourselves (vek has a Rect, nothing else provides this).

[dhardy]

#152 was supposed to reference this PR since it revised the geometry types. My decision (for now) is to keep the kas::geom::{Coord, Size, Offset, Rect} types indefinitely, and to look at replacing the floating-point types (Vec2 etc.) again in the future.

[dhardy]

Since #152 all sizing and layout is done using the i32 type, with drawing using f32 and some event handling using f64. (Before this, u32 was also used.)

For scrolling, it would be nice to use i64. This should only affect a small amount of code (from where ListView calculates content_size with multiplication to the ScrollComponent type), and lets us get significantly beyond current limitations (the dynamic-view example hits an overflow just beyond 20'000'000 items). Edit: content_size is an upper-bound for offset which is used for several things, including translated coordinates for children — thus probably all size types would end up being 64-bit if we do this.

[dhardy]

As noted, #152 made the decision to continue with home-brewed geometry types (at least for now).

Large scroll offsets are the topic of #222.