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.
the color type aliases have been a long time coming. it might make
sense to re-work the various color functions into some traits that
these color type aliases implement.
added the color function variants that accept and/or return 4 color
component arrays to aide in code that is doing more complex color
manipulation where it just makes more sense to always be working with
4 color component arrays instead of always converting to/from packed
and unpacked formats
this is based off what i saw some other libraries doing. i'm not sure
what is the "best practice" to be honest, but i definitely like this.
especially the prelude is now much simpler, which is nice.
Gered