I was curious about Louis’s comment about lower color depths, so I did some more tests with the latest library. Here’s some results running a plain bitmap test (no GIF decoding) with a background, scrolling, and indexed layer. These results are for Teensy 4.1 running at 600 MHz on the “Fastest” optimize setting. I’m using 32-row/mod16 panel size.
128x128
128x192
128x256
48-bit
121 Hz
82 Hz
62 Hz
36-bit
163 Hz
109 Hz
82 Hz
24-bit
244 Hz
164 Hz
123 Hz
15-bit
327 Hz*
220 Hz*
171 Hz*
9-bit
412 Hz*
278 Hz*
208 Hz*
With the lower bit depths (starred), I found that if I tried to set a refresh rate higher than the max stable value, the buffers would under-run and the driver would adjust the refresh rate all the way to 50-65% of the max before stabilizing. This probably explains why Louis was seeing lower refresh rates.
It looks like the 24-48 bit settings are HUB75 clock speed limited since they all are pushing about 96 million bits per second. But the lower color depth settings appear to be CPU speed limited instead. (If I overclock the Teensy to 816 MHz, I can get higher refresh rates for < 24 bit.)
I did some further digging and I think that the processing bottleneck is the code that extracts pixel data from all the layers (which is the same speed regardless of display color depth). Interestingly, it appears the majority of the CPU time is used decoding the scrolling and indexed layers.
No doubt with CPU-intensive rendering, the maximum refresh rates are going to be lower.
After disabling the indexed and scrolling layers, and making a minor speedup to the background layer I am now getting clock speed limited refresh rates at 9 and 15 bit:
Eric, thanks for looking into this. Scrolling I’m aware is inefficient, I wasn’t aware of indexed. I’ll have to take a look at some point.
If anyone thinks improving the efficiency of these layers is important for the next major release, please let me know. It’s not a high priority for me personally.
Tl;dr there’s a lot of updates to HUB75 code, and any existing projects using stacked panels need to be updated as SMARTMATRIX_OPTIONS_BOTTOM_TO_TOP_STACKING logic is now reversed.
The teensy4 branch has a lot of new updates:
I added the missing C-shaped stacking to all platforms, and added MultiRowRefresh to Teensy 4. In the process of adding these I realized that the SMARTMATRIX_OPTIONS_BOTTOM_TO_TOP_STACKING option was reversed. By default stacking was bottom to top, and enabling SMARTMATRIX_OPTIONS_BOTTOM_TO_TOP_STACKING would stack top to bottom. I fixed the logic, but anyone using stacking in the Teensy 4 branch will end up with reversed stacking logic when they update, so be careful there.
It turned out to be difficult to support MultiRowRefresh panels with C-shaped stacking, so they aren’t supported. MultiRowRefresh panels can only use Z-shaped stacking.
@easone’s loadMatrixBuffers() refactoring for the Teensy 4 is a lot easier to read, and is more efficient (~30% more) than my old code for Teensy 3, so I refactored the Teensy 3 loadMatrixBuffers() to get the improved efficiency, and also allowing kRefreshDepth to be any multiple of 3 instead of just 24, 36, 48.
I also added the hardware files for SmartLED Shield for Teensy 4 V5 (the production version that will be shipping to Crowd Supply backers).
I pushed some more updates today. A few things that will break existing sketches unfortunately, but hopefully the long term benefits are worth the temporary issues. Major changes that may break existing sketches, or cause some merge issues with forked code:
I renamed a bunch of files and classes to fit in this pattern SmartMatrix-Platform-LEDType-ClassType, e.g. SmartMatrixTeensy4Hub75Refresh
I renamed the MatrixHardware files to have a similar pattern, and to be more descriptive with the names e.g. MatrixHardwareKit_V1.h is now MatrixHardware_Teensy3_ShieldV1toV3.h
I replaced all instances of “Multiplexed” with “HUB75” in both file and class names as in the past few years calling these panels “HUB75” has seemed to caught on, and “multiplexed” is rarely used
I wasn’t perfectly consistent with using HUB75 vs Hub75, and I think I like the latter better e.g. SmartMatrixTeensy3HUB75Calc_Impl vs SmartMatrixTeensy3Hub75Calc_Impl so I’m going to do another renaming pass.
I still need to figure out what to do with the class and library name, as I foolishly named both “SmartMatrix3” instead of just “SmartMatrix”. I’m planning to rename them and request Arduino Library Manager to change the library name. I hope this doesn’t cause problems where people have an out of date “SmartMatrix3” library folder and a current “SmartMatrix” library folder, but I think changing the top of the sketch from #include <SmartMatrix3.h> to #include <SmartMatrix.h> and using the new MatrixHardware file name will sort things out, as these names will be unique to SmartMatrix Library 4.0, and the teensy4 development branch.