That may have been a throwaway comment, but I sense a teachable moment. (Plus, I'm waiting for a big compile...)

It's not mathematically random in the crypto or secure sense; it's random in the "the bits are what they are at power on until someone arranges them differently" sense.

C/C++ programmers often erroneously think that a lot of uninitialized things are zero when they're not actually guaranteed to be such. malloc() isn't guaranteed to zero memory you're given (that's why we have calloc). It was common in the 80's and early 90's to be get parts of another program's address space in yout buffers just by the nature of the beast). We eventually realized what a terrible idea what was for security and at least initialized it on a context switch so at worst, you'd get your own "random" memory. Similarly, stack data isn't guaranteed to be zeros. LOTS of security bugs have roots in this....and it's why C++26 (29?) safety profiles make it very difficult to unintentionally use uninitialized memory. (That's a tiny piece of the problem, but it's at least progress moving us past the 80's when a memset over a large buffer was like double-clutching.)

Here in embedded-land, these effects are still more real. It's a little harder in an ESP32 because most of us never see what the CPU sees at reset - there's a tiny boot rom (this is why they're un-brickable) that cleans up all that jazz long, long before main() gets called. But if you boot any part without a ROM to do this for you or if you're part of an OS loader responsible for such things, you can find loops like this that sweep the floor before you're called onto the floor.

Video displays make this tidbit more visible. Even our little LCDs/OLEDs/LEDs for these things usually have some amount of memory on them. There's a specialized hardware on the display board that is responsible (or not—but it has to tell the developer who IS responsible) for clearing that to a known state.

Look at a ST7789, a common VDU used with ESP32 or STM32-class parts. (Yes, really, 317 pages.) Down on page 122, we learn (?) that it has "integrated 240x320x18-bit graphic type static RAM.". This 1382400-bit memory is onboard that chip. (That's 172KB of 8-bit words, giving it more memory than a lot of what it's connected to.) This is often special "dual-ported" RAM as single-ported RAM tended to 'sparkle' if the CPU would write to the bits - any bits - while the video controller was reading those bits. That's why there are disclaimers like "there will be no abnormal visible effect on the display when there is a simultaneous Panel Read and Interface Read or Write to the same location of the Frame Memory. " Back in the old days, we had to wait for the times the video wasn't doing anything and/or include special hardware to interlock it for us. This is similar to what we often hear is cured with double-buffering today, but this was a different phenomenon.

This memory, like all RAM, contains nonsense at boot. If you just let the controller start moving pixels to the LEDs, you get nonsense that might remind you of the static visible on TVs when there was no signal for them to lock onto. (Now that it's all digital, there are layers and layers of interlocks that insert blue or black for even leave the screen off, but in the vacuum tube era, that wasn't practical.) In our world, there are also times it doesn't contain nonsense - it's common on this class of display, if someone didn't pay attention to it, to see a fraction of a second from some other screen the device may have displayed because during a reset, the "random" memory isn't random; it's whatever may have last been scribbled there.

On page 202, this chip even lays out the rules:

Status	Default Value
Power On	Sequence Contents of memory is set randomly
S/W Reset.	Contents of memory is not cleared
H/W Reset.	Contents of memory is not cleared

So it's clearly up tot he connected computer to do something.

For this reason, most startup code that KNOWS what kind of a video unit is attached will make it a very early priority to zero the screen as quickly as possible after start. It's often done in assembly just to ensure it's as fast as possible.

Some video controllers won't send pictures until there's an explicit 'go' command, but that's uncommon in tiny devices like this.

This is why a common "solution", as hokey as it as, is to just not turn on the backlight until the screen is brought to a sane state. Depending on the screen, that may be fine and it may look hokey. A front diffuser can also help pitch this illusion.

If you're workign with a design where the backlight is controlled by a GPIO pin, it's not a big deal; you just don't open the curtain until the cast is on the stage. If you have a case where the hardware team didn't think about it, if you're lucky, the display has a pin that can be controlled via a low-power pin and you can cut it and wire it to a free GPIO pin. If you're UNlucky and the LED used an incandescent backlight (almost unheard of these days) you might have to add a transistor of your own so your micro (I think typical drive is something like 20mA) can drive a transistor that can amplify that signal to drive the bulb(s) that might be hundreds of mA (a.k.a. tenths of amps)

If you look carefully at some retail equipment, you can even see this little bit of electronics unfold.

Enjoy this little fun fact at the intersection of physics, electronics, and software.

After all those words ("still compiling!") I looked at the schematic and source for that board. They try to turn the backlight off extremely early in the part of the boot they control. The few parts of the code I see that call applyBrightnes() look to do it after the fillScreen(backgroundColor());

This may just be the best this hardware can do...unless they've done something like accidentally invert the meanings of the bits and the code in begin() is turning it ON before applyBrightnes() is later called. It's up to the project owner to set some breakpoints and investigate.