Increasing scroll speed (and refresh rate?)

I’d like to achieve a text scroll speed in SmartMatrix that is extremely fast.

I’m running a simplified version of the Arduino IDE example “MultipleTextLayersGfx” on an ESP32 Rover module with Hub75 panels. It’s a 64x64 config.

I am finding that the fastest scroll speed I can achieve for the continuously scrolling text “Layer00” using FreeMono12pt7b (with “speed” = 100 and “setSpeed(255)”) is about 3 seconds per loop. Is there a way to achieve a faster speed? I’ve tried tinkering with some constants in the library’s MatrixEsp32Hub75xxxx files, with items such as maxCalcCpuPercentage, but not seeing faster speeds. When I try to alter the Refresh Rate from the sketch using matrix.setRefreshRate(), I typically get a Refresh Rate indicated in Serial Monitor of one-half the value I try to set. (e.g. set it to 240, see it set to 120.) It looks like the library MatrixESP32Hub75Calc_Impl.h is increasing a CPU divider based on it seeing too much CPU time used with the higher attempted Refresh Rate.

Since it looks like I’m probably going down a dead end with that idea, can you recommend any other ideas for speeding up the actually observed scroll speed? Ideally I’d like a max scroll speed (when selecting setSpeed(255)) that’s so fast it’s barely readable, and then I’d just throttle down from that with adjustable settings to allow for very fast options.

Thanks
Rick

Scroll speed is limited to one pixel shift per frame. If you want to change it to move multiple pixels, here’s a starting point for where to look:

Instead of framesperscroll you probably need to add a scrollsperframe variable, and change this function to run multiple passes at a time if scrollsperframe is > 1:

I don’t have time to comment on your refresh rate issue at the moment, LMK if that’s still important

Hey, a quick thanks. I’ve got high speed scrolling working on a demo, thanks to your assistance.

Rick

I’m running some experiments with the scrolling at normal fairly slow speeds as well as super-fast ones, and in both cases I’m seeing that wild swings in setting the refresh rate using matrix.setRefreshRate() (selecting 10 vs 500) seem to have no impact at all on the observed scrolling text. This makes me think I have an incorrect idea of refresh rate, or at least its influence on scrolling text.

In what kinds of situations would my changing of the refresh rate have any observable impact on a scrolling text or a playing GIF? Maybe if there were multiple layers scrolling at once…and then you might see some sort of flicker? (In my use case, I only will be using one scrolling layer at a time.)

Thanks
Rick

void SMLayerGFXMono<RGB_API, RGB_STORAGE, optionFlags>::setSpeed(unsigned char pixels_per_second) {
    pixelsPerSecond = pixels_per_second;
    framesperscroll = (this->refreshRate * 1.0) / pixelsPerSecond;
}

The code to set the scroll speed is in pixels per second, so it corrects for the current refresh rate when you set the scroll speed. Run FeatureDemo and look at the section that changes the refresh rate, I believe the scrolling text there slows down and speeds up as the refresh rate changes

I’ve got fast speeds achieved by following your suggestion of using a scrollsperframe variable. The speed amps up quickly as I go to shifting two, three, four pixels per frame as I increase my speed. I’m now interested in intermediate speeds. I’ve found that I can ‘average’ for instance 2.3 pixels per frame by shifting 2, 2, 3 in sequence repeatedly, but of course that induces some observable jerkiness.

I’m wondering if there’s a way to alter the time between shifts as a way of fine-tuning these speeds instead of trying to change the number of shifts per frame. i.e. make the frame interval 20% longer or shorter. This seems like a better way to achieve intermediate speeds.

What would be the most efficient way to alter the frame time by 20%?

In the “FeatureDemo” example, I’m seeing code that says “Changing Refresh Rate is Currently Broken in ESP32”. (We are running with a WROVER ESP32.) So I’m thinking that’s a dead end?

Thanks
Rick