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.
-
|
Agreed on leaving all the pain aside :) That's why I've done only simple lines/rects. But the idea to have same low-level implementation of updating DMA buffer in batches is too sweet to just throw it away :) Bit logic for DMA buff is quite complex to deep dive into it each time you need to cut some corners and squeeze more FPS from a single ESP32 :) As a general idea I would like to have a fastHLine-like method to render some arbitrary RGB vector. I believe it must be as simple and fast as possible, no coordinates transformations or H-to-V transpose, viewports, etc... just a row number and length. The idea is provide primitive to directly map RGB vector to the DMA buffer of the same pixel size, |
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.
-
|
that esp32 forum post is nice place to start for the one who want to write... an i2s library? Nah... Sometimes I want to stay within good old RGB bounds :) |
Beta Was this translation helpful? Give feedback.
-
|
I think newer revisions of the ESP32 coming in 2022+ (RISC-V version?) may support DMA from PSRAM/external SRAM etc. So that will be interesting to adjust this library for. i.e. FHD framebuffer display powered by an ESP32 might be possible lol. |
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