I have not had time to run it yet but I took a look at the repository. Is the graphics responsive enough? It renders everything on the processor side without using the hardware acceleration of LT7686, just transferring bulk graphics data.
In the mk3 design, I tried to simplify this → one of the RA8D2 cores rendering and streaming the graphics to the display using MIPI, keeping the rendering on the processor, without LT7686.
It’s very snappy for my purposes. I haven’t noticed any slow downs so far even with drawing (blitting) the large typefaces. To be honest, I wasn’t aware of the graphics co-processor or that my code wasn’t using it (when I looked at the schematics I was mostly interested in how the encoders were wired). I had a look into the LT686 and it looks a little bit old school? Meanwhile the RA8D2 looks like a total beast, and I also say it mentions it also has its own graphics acceleration functions (also it has a gigabit ethernet controller and a TSN switch! which is kind of crazy. I guess that means it could do AVB in theory). I see that LVGL has support for the Renesas H/W graphics acceleration.
@martin are you planning to make use of it? Ethernet with rtpmidi and network midi 2.0 sounds nice and future proof 
Comparing the two different graphics acceleration pipelines
I guess your firmware still renders everything on the MCU and blits it to the video controller. That works but of course it will be always slower than using built-in geometry and BTE engine. Electra almost never blits data.I’d say it is your call if you consider it sufficient.
Message from my agent:
The production firmware uses only the RA8876. Fills, rounded cards and vertical gradients use its draw engine. Gradient tiles and text are cached in RA8876 VRAM and composited with BTE copies onto an off-screen work page, then the changed regions are BTE-copied to the visible page. The MCU only streams pixels over SPI when it renders text that isn’t cached yet. Once the caches are warm, most updates push no pixels at all. Caches fill on first use rather than at boot, so the first visit to a page is slower (~180 ms vs ~85 ms warm). We benchmarked a D/AVE backend as an alternative and it was several times slower, so it isn’t used in production.
to note, my benchmark system measures 50fps on most operations within my GUI workflow
yup, that is the way to go. One more hint, for the fonts I use layered BTE bit expansion. That allows anti-aliased texts and using hardware of the RA8876/LT7686.
