Replies: 2 comments 3 replies
-
I love your enthusiasm @vortigont, but all I see is pain. My argument is if there's a desperate need to extract a last drop of GFX performance out of the ESP32, and essentially draw bare to the DMA memory without any of the adafruit abstraction, then they ought to fork the library and implement their graphics / sketch logic in the library itself lol and write directly to the malloc created for each row. The point of this library was to leverage the DMA capabilities, and abstract the pain away of doing so. |
Beta Was this translation helpful? Give feedback.
-
If one wants to implement a bare-metal graphics then starting with this sketch would be the way to go: https://www.esp32.com/viewtopic.php?f=17&t=3188 Funnily enough, ESP_Sprite's example code was the basis for this library originally... but subsequently built atop to make it Adafruit compatible (+ your excellent additions @vortigont) etc. Edit: Looks like somebody made a full-screen style buffer library, but obviously you lose the ease associated with this library: https://github.com/phkehl/esp32-leddisplay |
Beta Was this translation helpful? Give feedback.
-
I've got that idea of pipe-lining when I was playing with fillrate and implementing drawFast*methods. I found that function calls under esp32 is pretty heavy itself for CPU cycles, maybe it is related to instruction cache misses or whatever, not sure... But changing full row of pixels in a single tight loop is much faster than doing the same via drawpixel and external loop iterating the line. So let's take an example with some of the Aurora demo's - it works in a semi double-buffer mode. I mean it has it's own buffer in a CRGB vector for a single frame of effect and also DMA buffer for the matrix. First stage is calculating frame for effect over CRGB vector and second stage - copy vector buffer to the DMA buffer via drawPixel() using one pixel at a time. Now if we could use some kind of a drawFastHLine() but the one that accepts not just a single color for all pixels of a line but a reference to the vector buffer (offset and length) than the same approach could fill the entire row for the DMA buffer in a single loop. I expect it to be about 3 times faster than per-pixel approach with an external loop, maybe even more if being able to update two rows at once, top and bottom half of the same 16 bit word of the DMA buff.
But than comes but's and if's - it is pretty easy to implement for a single panel, but for virtual panels it's not that easy to provide a buffer vector matching a full virtual row covering the entire display. So, that's why I'm still thing about the way this could (or could not) be done in a nice way.
Any ideas?
Beta Was this translation helpful? Give feedback.
All reactions