previously, there were a ton of places that were allocating new Path
instances via `Path::new` for the purpose of creating a path to be
passed into a function as a Path argument
this has now been simplified everywhere by updating all functions
and methods that previously took Path arguments to instead take
AsRef<Path> arguments, allowing much more flexibility in the types
of path arguments passed in
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*
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
Gered