Built a slow-pan space screen for my desk and it finally runs smooth

When I built my own celestial display setup last year, the biggest pain wasn't the memory use, which was manageable, but the SD card readout speed itself. Even with the tiles chopped up correctly, if the card is slow, the whole show stutters becasue the ESP32 is starving for data. I ended up moving away from standard Class 10 cards and sticking to U3 formatted ones, even though they cost a bit more. It made the transition between the tiled sections much smoother.

I'm using a slightly diffrent tiling approach than you. Instead of just narrow vertical strips, I pre-process the image into overlapping horizontal bands. This gives the display a bit more breathing room during the scroll, which helps mask tiny hiccups in the data transfer. It’s not a huge improvement in overall flow, but it helps maintain a steady frame rate when the zoom is subtle. I found that running the code to update the screen buffer every single loop was also a bit overkill for a slow scroll. I implemented a timer so the board only refreshes the hardware panel every 500 milliseconds, regardless of the scroll movement. It sounds low-resolution, but for the huge mosaics, that reduction in unnecessary CPU cycles made the touch control responsiveness much snappier when I try to tweak the pace manually. It's a much quieter setup now, which is what I wanted.

My expirience with these displays was a bit different because I wasn't running the data directly off the SD card to the microcontroller. I used a Raspberry Pi Zero and kept the raw image files stored on a small cloud server instead. The bottleneck shifted from the physical storage readout to the decompression process itself. Even with the hardware scrolling on the panel, processing massive, high-bit-depth JPEGs every time the view shifted took up a lot of the Pi's CPU cycles.

I found that if you pre-process the mosaics into a simpler format like PNG tiles or even raw RGB buffers before transferring them, the display runs much smoother. The memory footprint for the Pi was acutally smaller that way, since the Pi wasn't having to hold and decode huge chunks of visual information at runtime. It seemed like the Pi was spending too much time just figuring out where the next line of color should go rather than managing the scrolling motion.

For a project like this, where the speed is alredy incredibly slow because of the vast data set, reducing the computational load on the processing unit is the best way to eliminate any jitter. I ended up scripting a small Python tool that converts the full TIFF files into optimized tiles specifically for that board's color depth before I ever plugged anything in. It saved me a ton of headache down the line.

I've run into a problem with the visual quality of those tiles when they're scrolling really slow. It seems like the JPEG compression settings are crucial here. If the image quality is set too low, you can get these wierd blocky artifacts showing up when the panel is moving, even if the data transfer is flawless. Have you fiddled with the output quality setting on your original image slices? I wonder if that would help maintain the clean look over a week-long scroll.

You guys are making this way too complex with all the tiling and memory tricks. Back when I was doing this kind of project, we weren't dealing with ESP32 memory limits. We just bit into the data and streamed it directly from a hard drive to the display controller. It wasn't pretty, and the wiring looked like a rat's nest, but you didn't have to think about 'slicing' the image or optimizing refresh rates every loop. Simplicity always wins in the end, even if the setup is a bit of a mess.