[TODO] OLED update procedures could be optimized more

[SeongGino]

An observation I've had, but frankly couldn't find the time for it during the overhaul update dev cycle, is that the display drawing routines could benefit from a similar queuing system that the input system uses now as of v6.0.

Basically, when calling to draw something new to the display, the act of drawing to the backbuffer should be as-is, but instead of drawing immediately at every one of these updates (i.e. calling display() with every menial change), it should mark the display as "ready to update" when it has new contents. Then, during OLED.IdleOps(), we should check if that "ready to update" flag is called, and if so, call display() then.

Ideally, maybe OLED.IdleOps() shouldn't be called every cycle that the camera isn't active? Perhaps only the cycle after the cam is read, since all I2C ops need to be done sequentially from the primary core (to avoid e.g. glitchiness that was present in cases when the second core called for screen mode updates). I did notice, since adding #69 (nice), it seems like simply displaying updated temps somewhat impacts the camera update rate down to about ~189hz? But then again, if we want to support other cameras in the future, would that still work? Does the display have an effective "framerate"? I could be a little paranoid thinking about this in too much detail, honestly.

Also, we are using Adafruit's display library pretty much off-the-shelf, but it could be beneficial if we modify how the library handles I2C transmissions to (for ARDUINO_ARCH_RP2040, obvi) offload it to use async transmits using DMA as provided in the SDK? Heck, since we can have access to the library's back buffer, and since it's mainly exclusively one-way messaging (from board to display), it should be a no brainer, yeah?

Because life's taking a toll on me lately, and I put off so many things just to get this past batch of updates out the door, I don't think I'll have the time or mental energy to do this myself atm (at least, maybe not till late summer or late fall), so leaving this note-to-self to the public in case someone wants an experiment to play with.

[SeongGino]

#124, as suspected, is proof that the bottleneck is simply in sending data to the display, not the actual calculations or drawing to the backbuffer. Simply commenting out the display() call at the end of DrawVisibleIR gives us back our full cam update rate.

So yeah, we might very much benefit from using some async DMA magic here. It might be so slow that we'll have to guard said buffer and then use the finished callback to unlock it afterwards.

[alessandro-satanassi]

you could try to use this library (https://github.com/lovyan03/LovyanGFX) that works on both rp2040 and esp32 as well as other micros, but I personally don't know it, I had only looked at it some time ago to do some tests... and it seems to me that it worked, but I can't say the real advantages it can bring with i2c connections

[SeongGino]

That's pretty clearly an ESP-tailored library, and doesn't even claim HW support for RP, so uh... no?
It's not the library itself that's the problem (and I'm not looking rn to support every single kind of display under the sun), but just how the lib uses Wire transfers. No matter what, it's going to need to be RP specific to get around the main bottleneck, which is IIC transmissions.

[alessandro-satanassi]

On their website it says that it is compatible with ESP32, RP2040 and other micros... I tried to compile it for both esp32 and pico RP2040 and it doesn't give any errors... but I haven't tried it yet... as you prefer

[SeongGino]

Again, the goal is not to change out the whole library because that's a whole hell of a lot more baggage than "just" compiling a different lib. And I'm going to lean towards RP-specific solutions anyways, since this is clearly an RP-specific repo.

That library doesn't even use async transmits, so it doesn't solve the problem regardless.

[alessandro-satanassi]

If you want to try it out of curiosity, I made an adaptation with very few changes to OpenFIREdisplay.cpp and OpenFIREdisplay.h, just set a #define USE_LOVYAN_GFX (it also works well on rp2040) .. it seems a little more performing, but I don't see that much of a difference (maybe it's just a suggestion, I think that big differences would be seen on larger displays and maybe spi).

[SeongGino]

I already told you

It's not the library itself that's the problem (and I'm not looking rn to support every single kind of display under the sun).
But, uh, good for you i guess? Original points still stands. :|