| 11 Nov 2024 |
 almindor | that's what I planned as a super low hanging fruit improvement | 00:18:46 |
| almindor | you can then just do let di = SpiInterface::with_buffer_size::<256>(spi_device, dc); kind of thing | 00:19:15 |
 GrantM11235 | A user provided slice can be more dma-friendly | 00:19:20 |
| almindor | although providing a buffer is even better coz if there's DMA to be done manualy or such | 00:19:27 |
| almindor | yeah | 00:19:29 |
| almindor | i wonder considering the use case here (e.g. fill_solid) if the buffer should also be made accessible | 00:21:18 |
| GrantM11235 | You mean like so you can "save" a buffer full of BLACK somewhere to reuse later? | 00:22:32 |
| almindor | no, more so that we don't waste memory re-buffering | 00:22:51 |
| almindor | if DI is given a buffer, then mipidsi inside fill_solid for example shouldn't make a new buffer | 00:23:06 |
| almindor | it'd mean we can OOM | 00:23:12 |
| GrantM11235 | mipidsi shouldn't have it's own buffer for fill_solid, it should just tell the interface to do that | 00:23:58 |
| almindor | you mean repeat_pixel call | 00:24:10 |
| GrantM11235 | yeah | 00:24:18 |
| almindor | or I guess more like "repeat data" | 00:24:26 |
| almindor | hmm that works, but isn't it kind of very specific? | 00:24:36 |
| almindor | feels like we're outsorcing graphics logic to the interface at that point | 00:25:00 |
| GrantM11235 | The interface is in the best position to decide whether to buffer the data or not. For example, a non-dma parallel interface wouldn't waste time or memory filling a buffer, it would just send the data out pixel by pixel | 00:28:07 |
| almindor | true, it does mean we want to have a good enough "intention retention" in the API | 00:29:09 |
| almindor | I think that in combination with a BE default storage for pixel data could be a nice win | 00:29:31 |
| GrantM11235 | I'm not sure how much switching to BE would save. I think it should only add one instruction per pixel, which at 320x240 and 160mhz, is only 0.48ms. That's the difference between 60fps and 58.3fps | 00:40:52 |
| almindor | still, why do LE if almost all displays expect BE? | 00:41:49 |
| GrantM11235 | It would make it more expensive to manipulate the green value, but I'm not sure how common that is | 00:46:24 |
| GrantM11235 | 16bit parallel interfaces would prefer native endian, not to mention all the framebuffer-in-ram e-g impls on bigger chips and on desktop | 00:53:09 |
| almindor | I think it should be a switch | 00:54:42 |
| almindor | not sure if it'd be easy to expose on "globally" for e-g though, might not be worth it | 00:55:02 |
| almindor | it'd also have to be accessible compile time inside, so that the drivers could just go "ah native, cool don't process, just send" | 00:55:31 |
|  @dark_therion:matrix.org left the room. | 03:13:15 |
| almindor | GrantM11235: well, I was able to get https://github.com/almindor/mipidsi/pull/145 in. It's not particularly great looking but it does the job with minimal duplication, speed went down from 48ms to 18ms (pure buffer fill is 12ms) | 20:26:48 |
| almindor | a bigger rewrite is warranted with DI as well as some better design wrt. buffer usage overall | 20:27:04 |
| almindor | i'm still unsure if I want the repeat_pixel_to_buffer optional or not for Models. forcing it seems better so there's no "unoptimized path" for fill_solid, on the other hand it'd mean incompatibility with existing external models and a major version bump | 20:31:28 |
