| 12 Nov 2024 |
 almindor | coz the DI just sees an Iterator<Item = TransportNativeUX> (e.g. u8 or u16 really..) | 22:53:24 |
 GrantM11235 | Why does the interface care if you are sending contiguous pixels or not? | 22:54:14 |
| almindor | how would it know when to terminate the spi session? | 22:54:32 |
| almindor | I mean say you're doing a circle, top few pixels (say 3) are contiguous, then next line it's 7 pixels etc. | 22:55:09 |
| almindor | right now we pre-buffer the 3, do a send of 3, pre-buffer the 7 etc. | 22:55:21 |
| almindor | in between you need to call the window addressing to move the positions | 22:55:43 |
| almindor | so it's saving us SPI sends, but also window addressing calls (another SPI send) | 22:55:56 |
| almindor | with the callback hack, I guess this could work in a way where the DI just buffers the bytes until it gets back "non-contiguous" answer, and inside the callback, the driver would actually move the window as well | 22:57:04 |
| almindor | but it also needs to be the right order, e.g. the 1st buffered stuff needs to be send out before the window call is made to move the position | 22:57:51 |
| almindor | not easy to ping-pong this if the driver is not to use its own buffers | 22:58:04 |
| GrantM11235 | In reply to @almindor:matrix.org
right now we pre-buffer the 3, do a send of 3, pre-buffer the 7 etc. You don't need to pre-buffer, you can just optimistically set the window and keep sending pixels as long as they are contiguous | 23:00:40 |
| almindor | ok, so you're saying call next in a loop, check continuity, if ok then what.. do we expose a "stack" of sorts a stateful setup in the DI? I guess it could work with some sort of next_pixel and flush approach | 23:02:03 |
| GrantM11235 | You can turn an impl Iterator<Item = (Position, Color)> into an impl Iterator<Item = (Position, impl Iterator<Item = Color>)> | 23:05:22 |
| GrantM11235 | Where each item in the iterator is the start position, and an iterator of all the pixels that start there and continue on the same line | 23:06:28 |
| almindor | I assume you actually mean Item = u16 or u8 ? I don't think the DI should know about colors? But even so, how would this work? You NEED to walk the original iterator from embedded-graphics, and as you go you need to keep the values "somewhere" so you can then send them off | 23:07:47 |
| GrantM11235 | You only need to peek one pixel at a time | 23:08:49 |
| almindor | I don't know when to "switch to a new position" until I walk all the pixels and find a one that's off. All the previous ones need to be somewhere (they cannot be sent yet) | 23:08:52 |
| almindor | I think a buffer_data and flush_buffer interface would work ok here | 23:16:11 |
| GrantM11235 | (btw, I think the DI does need to know about colors, unfortunately. I don't remember the exact details, but it involves weird packing with the more obscure interfaces and pixel formats) | 23:17:29 |
| almindor | we could push the color -> byteorder transform into the DI, it's probably beneficial for some interface types (e.g. parallel) | 23:18:22 |
| almindor | not sure if there's a downside yet | 23:18:31 |
| GrantM11235 | This should let you take an iterator of (position, color) and make sub-iterators of contiguous pixels https://doc.rust-lang.org/core/iter/struct.Peekable.html#method.next_if | 23:21:01 |
| GrantM11235 | Then just pass those sub-iterators to fill_contiguous | 23:22:00 |
| almindor | but e-g draw_iter doesn't have that binding (Peekable) AFAICS | 23:38:55 |
| GrantM11235 | You can make any iterator peekable https://doc.rust-lang.org/core/iter/trait.Iterator.html#method.peekable | 23:40:52 |
| almindor | so pixels.peekable().next_if(|p| ...).map(|p| ...) kind of thing? | 23:46:42 |
| almindor | wouldn't that be single shot only though? I'm a bit confused how next_if works wrt. continuing | 23:47:20 |
| GrantM11235 | It would be something like
let mut peekable = pixels.peekable();
loop {
| 23:49:09 |
| GrantM11235 | * It would be something like
let mut peekable = pixels.peekable();
loop {
let sub_iter = peekable.next_if(|p| ...).map(|p| ...);
...
}
| 23:49:54 |
| GrantM11235 | Well, not quite. You would need to create an iterator combinator that uses next_if for it's next | 23:52:50 |
