Announce: Framebuffer::GFX and FastLED_SPITFT::GFX

Ok, it’s a bit off topic, but since @Louis was interested, he probably won’t kick me out for posting this :slight_smile:
I’ve refactored my multi API setup in as base class

If you use , you’ll be talking to it.

In turn, you can then substitute your RGBPanel(s) for a small TFT and display your same code with pretty much 0 work:

More details:

Good work Marc, thanks for sharing!

Do you have a project in mind for this?

I’m in the early stages of a VJ controller for LED wearables, and eventually want to add a feature to Aurora so it can sync timing of Aurora patterns over RFM69 radios to nearby wearables also running Aurora. The VJ controller would be handheld, and using one of these tiny OLEDs. The VJ controller radio wouldn’t need to send a lot of data; it’s not sending the full frame buffer, just pattern and timing information, like this project for the PixelBlaze controller does:

Actually in this case, not really, I just ended up with some small TFTs and I figured I’d do this for fun, and also as an exercise to help factor our my framebuffer library into a base class.

That being said, it’s cool to be able to write code and test it easily on a trip without carrying big panels and wires.

yeah, it would work great for such an application.

Looking forward to seeing your work :slight_smile:

Hi Marc, SmartMatrix Library 4.0 is ready for release, and merged into master. It won’t work as is with your libraries, as SmartMatrix3.h is replaced with SmartMatrix.h or SmartMatrix4.h. There’s some new #defines to identify version, check out SmartMatrix.h. Hope you can get your libraries running with SmartMatrix Library 4.0, happy to help if you need it

Check out the updated Migration doc

Also I’m going to be requesting the Arduino Library Manager renames the library SmartMatrix, instead of SmartMatrix3, which might screw up Arduino Library Manager dependencies temporarily, but will be better in the long run

Thank you for the heads up @Louis , will have a look.
Remind me: you’ve actually made part of SmartMatrix::GFX redundant. I however offer further compatibility with FastLED and LEDMatrix, while you’ve integrated GFX support in 4.0. Is that correct?

Yes, I believe with some work, you could connect your Framebuffer::GFX directly to the Background_GFX Layer. Here’s where we were discussing that:

LMK if you need help with passing a pointer to a templated class or anything else if you want to take on this work.

Hi @Louis: first questions

  • Your new SmartMatrix is definitely a step up/different from the old 4.0 where all the stuff was in teensylc. Would it make sense to call this one 4.1 or even 5.0 given that it’s a pretty big merge and upgrade with the integrated GFX support?
    => mmmh, I think the old lib was actually smartmatrix3, but i was confused because of #include <SmartLEDShieldV4.h>. So, basically you did upgrade from 3 to 4, my bad.

  • I looked at your GFX support and I’m a bit confused as to why it’s not default and why one needs to use different define macros (SMARTMATRIX_ALLOCATE_BACKGROUND_GFX_LAYER) on top of defining SUPPORT_ADAFRUIT_GFX_LIBRARY
    a) shouldn’t defining SUPPORT_ADAFRUIT_GFX_LIBRARY be enough?
    b) if there are costs/drawbacks to enabling it, and that’s why you didn’t make it default, can you give more details on that?

  • Obviously adafruit::gfx is only 16bpp while you allow all the way to 36bpp. Does it mean that when you use GFX primitives, you have to use RGB565 even though the back buffer could be 36bpp?
    Is there a way to use the passthroughcolor trick?
    Actually, looking at your code, it looks like the line primitives go directly to our library (bypassing GFX and it’s 565 color limitation), but fonts go to GFX with the color limitation (which for my own use is really not an issue)?

Basically it’d be great to have a GFX section in your, explaining some of the points above :slight_smile: