dev/test builds that heavily use deflate (e.g. anything with png files)
perform *incredibly* slow with 1.0.28. also tried switching the backend
to zlib which didn't really speed things up too much.
i hate updating dependencies. *sigh*
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 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