FastLED: Faster "moving pixel" on WS2812 matrix; FastLED.show() is slow -.-"

Hello everyone, i would highly appreciate any meaningful thought regarding a timing problem with my WS2812-matrix. It’s not a precision problem as in “is my delay(1000) really 1000ms long?”, it’s about pure speed 😃

project outline / motivation: I intend to measure the delay of multiple cameras triggered by the same release signal. I expect 0-10 ms delay values. Therefore, I thought of a quick LED dot toggling through a 256-pixel WS2812 matrix as fast it can. I capture the matrix with my cameras and from the resulting images I can deduct the camera delay (Picture1: “The dot is at line8, pos3.”, Picture2: “It clearly is at line8, pos5, screw you!”)

problem / symptoms: Even in a minimal case, I can’t beat a time delay of 9ms from frame-to-frame (LEDposX-to-LEDposX+1) on my moving-dot-matrix. Correct me if I’m wrong, in my understanding that corresponds to a frame rate of 111Hz, while the technical limit of the WS2812 itself should be at 400Hz.

minimal:

#include "FastLED.h"
#define PIXEL_TYPE NEOPIXEL
#define NUM_LEDS 256
#define DATA_PIN 6

CRGB leds[NUM_LEDS];

void setup() { FastLED.addLeds<PIXEL_TYPE, DATA_PIN>(leds, NUM_LEDS); }

void loop() {
        for(int dot = 0; dot < NUM_LEDS; dot++) { 
            leds[dot] = CRGB::Blue;
            FastLED.show();
            FastLED.clear();
        }
 } 

sloppy eigendiagnosis: So obviously, the time-consuming part is NOT preparation of pixel (see video in link below, a lot more to do, yet same speed), but the actual sending through the FastLED.show() command. Adding a delay(1) does not change anything, a FastLED.delay(1) makes it even slower (18ms / 56Hz). Right now, I’m running the code with no delay at all. Played around with “EVERY_N_”-stuff, Adafruit library (boo!), didn’t help.

setup: Hardware: Arduino UNO, 5V/16A-PWRsupply, WS2812-Matrix (256 LEDs), 1000uF capacitor, 470Ohm resistor Software: FastLED 3.1.6 Video snippet of code I actually intend to use: https://streamable.com/vtbze Measurement: stopwatch, 10 cycles => divide by 10*256 => “frame time” of roughly 9ms

QUESTION 1 Basically, why is it that slow? Or in other words, is there a way to update LEDs faster? In my opinion, each new pixel movement requires a FastLED.show() call because the position is updated and it is a different set of information than before. Can you “magically speed up” that function call? Not an experienced person here, obviously…

QUESTION 2 Does anyone have a smart thought on how to create another ON/OFF-pattern or some other sort of visually distinguishable pattern that runs quicker than 9ms/frame and that maybe doesn’t require a FastLED.show() call every iteration?

Thankful for any advice and/or opinion! If you need any more information, drop a note, I’ll post everything that may help the case.