| 13 Jan 2024 |
 Dominic Fischer | In reply to @bugadani:matrix.org
btw have you considered making this change on the driver level? * I chose to DIY the driver and decided batching up draw_iter calls wasn't something display driver should have to do. The caller has the most information and should reduce the draw calls were possible. IMO | 12:49:16 |
| Dominic Fischer | In reply to @dominaezzz:matrix.org
Setting up a traditional framebuffer to for the whole screen 800x480 would take 768KB, which won't fit in the internal RAM of the device. PSRAM is an option but it's too slow and has awkward bandwidth issues. So to fit the frame buffer in internal RAM I'm taking advantage of the linked list nature of the esp32's DMA to send the same chunk of color repeatedly to the screen. | 12:50:28 |
| Dominic Fischer | Then to render stuff for DrawTarget I just insert new descriptors pointing to a new buffer with the desired colors. | 12:51:25 |
| Dominic Fischer | Unfortunately when the draw calls are pixel by pixel the descriptors become tiny and the GDMA starts to struggle 😅 | 12:52:06 |
| Dominic Fischer | * Unfortunately when the draw calls are pixel by pixel, the descriptors become tiny and the GDMA starts to struggle 😅 | 12:52:20 |
 danielb | uuuh | 12:52:43 |
| danielb | so you've optimized for fill | 12:52:52 |
| danielb | that's neat | 12:52:56 |
| Dominic Fischer | Pretty much | 12:53:06 |
| Dominic Fischer | So that's my setup 🙂 | 12:53:20 |
| danielb | I can see what is basically an RLE-encoding of the draw calls working for you | 12:53:46 |
| Dominic Fischer | Precisely that! | 12:54:09 |
| danielb | what makes me somewhat iffy is that this feels like overhead for small devices/small displays. The fonts I'm rendering are like 7x13 tops, though still on the S3 so CPU time is not a problem. But for devices that are an order of magnitude smaller, just pushing out the pixels one by one might just be more efficient (or not). | 12:56:04 |
| danielb | this also feels like a technique that could be implemented as a wrapper around the font types, or between embeddedgraphics and the display drivers | 12:56:56 |
| Dominic Fischer | On these devices you're rendering on, how do interface the display? SPI or I2C? | 13:00:07 |
| Dominic Fischer | I still think the batching could improve performance in these cases, depending on the font I suppose | 13:00:31 |
| danielb | I'm dumping frames from a frame buffer with SPI. So essentially your batched calls go into RAM | 13:02:13 |
| danielb | * I'm dumping frames from a frame buffer with SPI. So essentially your batched calls would go into RAM | 13:02:30 |
| danielb | my display's framebuffer is uh... 1KB? | 13:03:12 |
| Dominic Fischer | Ah yeah the batching would be overhead for an on chip framebuffer. | 13:04:15 |
| danielb | one more thing | 13:04:40 |
| danielb | my driver doesn't implement fill_solid, so collecting into a rectangle then drawing that ends up calling draw_iter anyway | 13:05:16 |
| danielb | it's certainly something that could be improved in the driver, but so far there was not much reason to do so | 13:05:42 |
| Dominic Fischer | Even for my traditional framebuffers, I had to implement fill_solid to reduce the significant amount of bounds checking that was needed. Though for a 1KB framebuffer in won't matter. Pesky | 13:07:46 |
| danielb | yeah the joys of small things :D | 13:08:12 |
| Dominic Fischer | I now wonder if the fonts could be stored as an RLE format. 🤔 | 13:08:14 |
| Dominic Fischer | Then everyone can win. Less space, less draw calls. | 13:08:35 |
| danielb | maaaybe? pretty big change, though if you want to tackle that | 13:09:31 |
| danielb | at least on the current monofonts, though you could whip up some experimental new font type | 13:09:48 |
| Dominic Fischer | New font type for that makes sense to me as well | 13:10:11 |
