- Renamed to `ImColor32` to avoid confusion with `ImColor` from the C++.
code: https://github.com/ocornut/imgui/blob/9499afdf/imgui.h#L2180
- Eventually I'd probably like to add something mirroring the actual
`ImColor`.
- Now supports construction and access from `const fn` where possible.
- Still impossible for the `f32` APIs
- Now supports `.r`/`.g`/`.b`/.a` field access (read and write), by way
of a new type `imgui::color::ImColor32Fields`, which essentially
exists just to serve this purpose. This is a bit cludgey, but lets us
provide the ability for reading and writing `r/g/b/a` values without
adding many `fn get_r(self) -> u8` and `fn set_r(&mut self, r: u8);`
style functions.
- No longer requires FFI calls to construct from RGB floats.
- This gives much more freedom to the optimizer, as external calls
are impenetrable optimization barriers (It has to pessimistially
assume that they read/write to all globally accessable memory, and
must be called in the exact order that is listed).
- Also, it allows inlining these calls, and avoid computing the same
value twice (if the args are the same).
- Also improves usage from IDEs, debuggers, etc, and avoids a rare
possibility of UB if NaN was passed in (however, this almost
certainly could only cause problems if cross-lang LTO was used,
which I believe we don't support).
- This code is more complex than needed, but was taken from another
project of mine (functions were renamed to line up with imgui's
names), and has good (literally exhaustive) test coverage.
- Unfortunately, float arithmetic in const fn is still not allowed,
so for now these aren't usable `const fn`.
- Added utility constants to mirror the `IM_COL32_WHITE`,
`IM_COL32_BLACK`, `IM_COL32_BLACK_TRANS` constants.
We can't promise forward compatibility with arbitrary versions, and 0.22
is already broken -> require 0.20 or 0.21, and let's upgrade to 0.22
properly later.
This is probably going to be controversial...
Calling end/pop in the Drop implementation causes way too many problems,
and interacts very badly with panics.
There are closure-based simpler implementations of almost everything
except parameter stacks that are still convenient to use. However, if we
end up switching to &mut Ui in most functions (very much possible in the
future!), closures will complicate matters so push/pop and begin/end
pairs are still relevant.
