| 13 Jan 2024 |
 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 |
| danielb | so, to summarize, I think you should create some third-party adapter that does your iter -> Rect conversion, so people could opt in if/when/where they want to | 13:11:45 |
| danielb | it's also probably a better way initially to not bug the otherwise half-gone maintainers :) | 13:12:23 |
| danielb | but you're right that there are opportunities for improvement | 13:12:43 |
| Dominic Fischer | Sounds good to me. I'll probably skip the iter -> Rect thing and just do the custom font. | 13:15:47 |
