| 13 Jan 2024 |
 danielb | out of curiousity, is this a meaningful improvement? I don't have measurements, but I'm assuming that the impact on my host of SSD1306 displays would be somewhat different than what you are aiming for | 07:45:25 |
| danielb | * out of curiousity, what is your setup and what kind of improvements do you see? I don't have measurements, but I'm assuming that the impact on my host of SSD1306 displays would be somewhat different than what you are aiming for | 07:51:47 |
 Dominic Fischer | My setup is https://www.makerfabs.com/esp32-s3-parallel-tft-with-touch-4-3-inch.html + esp-idf-hal + esp-pacs. | 12:45:31 |
| danielb | wow that looks like a sweet bit of kit | 12:46:08 |
| Dominic Fischer | Yeah it's nice and compact, no wiring required | 12:47:26 |
| danielb | btw have you considered making this change on the driver level? | 12:47:40 |
| Dominic Fischer | 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. | 12:48:09 |
| 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. IMOP | 12:49:14 |
| 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 |
