i suppose there is not much benefit to using this versus equivalent
functionality on SystemResources (for example). however the dimensions
returned by these new methods do respect whatever display scaling is
being used by ImGui. and these are technically more convenient to use
in whatever place you're building up a UI in. meh.
as well as support for directly instantiating a BitmapAtlas from
such a descriptor.
saving a BitmapAtlas to a descriptor file directly is not added (yet?)
as my gut feeling is that these files would probably be hand-written?
saving from a BitmapAtlas directly would (in a simple/naive impl)
always result in a long-ish list of "tiles" anyway, since grids are
turned into tiles. this further reinforces me feeling that you'd either
write these files by hand, or at the very least, just construct a
descriptor instance in code somehow and save that
plus these are easier to type.
i do not anticipate needing structured color types for any other
type of components (e.g. i don't see a need for an ARGBu16x4, etc).
so i am fine with just having `ARGB` being associated with four u8's
with no real indication of this in the type name itself.
our target is IndexedBitmap's will use PixelType=u8 and
RgbaBitmap's will use PixelType=ARGBu8x4
thus, restricting the Pixel trait to primitive unsigned numerics won't
work anymore, but we do still need to support basic stuff like
equality testing and copy/clone support for our generic bitmap
operations
of course, here we immediately must question whether this is abuse
of operator overloading or not. since you cannot otherwise multiply
these types together, i think this is fine. plus we are not providing
any other math operations via operator overloading, so this feels like
a very explicit thing to do
two primary goals with this change:
1. test triangle dimensions of varying widths, in preparation for
upcoming simd per_pixel_triangle_2d changes. we want to ensure that
scenarios where `width < 4` and `width % 4 != 0` continue to work
fine after simd changes are done
2. test triangle rendering at various rotations, because i remember
while testing fill rule changes, sometimes issues would only be
visible at certain rotations. so this is mostly just useful for
blended rendering methods, but still, is probably generally useful
too ...
i did not expect this to be problematic so soon, based on what i'd
read in various places about the stability of nightly (especially so
for the most common platforms like x86_64, etc)
as i write this commit message, all nightly versions past this date
fail to build ggdt, failing with an "illegal instruction" error.
sigh. this makes me question whether trying to use simd right now is
actually worth it ...
i really did not want to use nightly, but i think it is worth it for
portable_simd which is still nightly-only (and i'm guessing will be
for a long while still). i was not particularly enthusiastic about any
of the alternative libraries that exist for stable rust simd, as it
always seemed like something small was missing from what i knew i would
want longer term.
Gered