but there are still performance improvements we can make. but at least
now we're not doing some silly double-pixel draw as a band-aid over
missing/gap pixels. and we no longer sometimes have missing scanlines
due to floating-point rounding issues.
mainly switching #[derive(Debug)] to manual std::fmt::Debug impls to
remove debug strings that would otherwise contain long strings of
byte arrays which most of the time isn't so useful to see in any kind
of debug logging
this might still need to be tweaked still as benchmarks are showing
some performance loses (though, also, some minor performance gains?)
so i guess the lambda functions may not always be inlined, or if they
are, the optimizer isn't able to do the same level of optimizations as
it was before? unsure as of yet, so need to investigate further.
however, none of the performance regressions were huge, so i think this
is acceptable to me for now.
libretrogd was never intended to push performance boundaries anyway :-)
rename the old "apply" to "apply_to_device". meh. naming is hard.
i expect that most of the time i'd want to use the "apply" method i'm
adding here that handles device locking internally, so that is why i've
chosen to let it be called "apply" and to rename the other one.
this is more useful because playing/stopping can be done on a specific
channel more easily by specifying a channel index. and the index can
obviously also be used to get the channel itself when/if needed, but
it's not super convenient to get the index of a channel when you only
have the channel itself
for queuing audio "commands" which is a much nicer way to interact
with the audio system in general in a more complex application, as this
lets you play audio in more of a "fire and forget" kind of way.
Rc<AudioBuffer> play methods provided as an alternative because
otherwise you end up with a somewhat gross double-copy of the audio
buffer being played. but i didn't want to necessarily force use of
Rc<AudioBuffer> just yet ... thus both versions of these methods are
provided.
Gered