Alex

Is it really necessary? Yes, it's beautiful, but the huge amount of closures in futures will dramatically increase the stack. Isn't it?

I suppose that pattern was dropped. Inner implementation of color is - usize 0..=3 is color - usize >4 is interpreted as pointer to array 8*8 So there's pointer to...

Agreed. This is next in my queue.

Any suggestions? I have no good idea yet, just allow to store only `&'static` pattern in the `LCDColor::Pattern` ([e.g.](https://github.com/boozook/playdate/pull/156/files#diff-4587a32f89031168a7d8bfc99fe9e875b047e73d3268e791ae199c60dc62649dL13-L32)). Also maybe allow something with `!Unpin` 🤷🏻‍♂️ I'll look at it...

Also there is problem with `bitmap.set_color_to_pattern`. 1. create `color` 2. create filled `bitmap` 3. `bitmap.set_color_to_pattern(&mut color)` (or something like that) 4. change or drop `bitmap` Color, as we know, is...

It with be great. Of course, no pressure, just say no if you don't want to. The assignment is just a hint to attract attention.

Good point. Your PR would be very helpful here. _Also it's already done in [other project](https://github.com/boozook/playdate)._

There's stabled custom allocator error handler. I'm not sure that is it but I'll look in in couple of days on latest macOS M1.

Awesome find, thanks! Is it breaking change for other users? 🤔

Thanks you! I've [solved](https://github.com/boozook/playdate/blob/main/api/gfx/src/bitmap/bitmap.rs#L342) this problem with const-generics. I have to think more about your thoughts and this solution. 👍 And `BitmapDataMuts`-like - [there](https://github.com/boozook/playdate/blob/main/api/gfx/src/bitmap/bitmap.rs#L122).