I am using a Rpi 4 + Adafruit HAT + six pieces of 64 x 64 Waveshare led panel in one chain.
When I run a version of the Python examples like “image-scroller.py” or “runtext.py”, which translate the content along the x-axis, the top half of the screen updates slightly slower than the bottom half, so the top half is always a few pixels behind. When the translation is slow, it is not so disturbing, but when I speed it up, it looks like the content is cut in half, with the top half distorted to the right.
I am currently running this example script:
The only changes I made were to increase the speed on line 23 and to add an y translation to the image on lines 27 and 28 to make it more centred:
I’m not familiar with the python interface and how slow it may be, or not, but I’ve never had such visible update delays like this.
There is indeed code to fill one buffer fully and only make it available to the library once it’s completely full, avoiding any tearing issues, but I’d have to recommend you go back and look at the API carefully. If you use proper double buffering and only flip buffers once they are full, this should never happen
I have this same problem occurring with the python runtext.py example. When my text scrolls with a 1 pixel change on each update, the bottom half of my 64x32 matrices ends up being one pixel further to the left than the top half; as in, the bottom half ends up being a frame ahead. I haven’t been able to figure out how to fix it either.
Hello, I am having the same problem with runtext.py, and witth the demos it works fine except it is going at a way slower speed! Do you know why it works with the C code and not the python?
Update, I tried a faster speed with the C demo ./scrolling-text-example and still the same issue, (I turned off sound, I tried various GPIOS, I added isolcpus, etc)
Here is a video using the C code, notice here the delay is only 1 pixel as the C code I assume shifts pixels by one each time: https://youtube.com/shorts/F8_VxzetkHA
Watch closely we see it especially with the capital T at the start! the delay is much more apparent when looking at it with the human eye from far!
The command I used was
sudo ./scrolling-text-example -f ../fonts/13x26.bdf -C 255,191, 0 -s 5 "TEST … " --led-cols=128 --led-rows=32 --led-slowdown-gpio=4
Do you think it has to do with the wiring? or the software? or anything else?
Got it. In that case it sounds like the python code is updating the framebuffer without double buffering. It should update a framebuffer and when it’s done, swap framebuffers and tell the driver to display the newly rendered one.
It’s probably less visible with C because C is much faster
honestly I haven’t written or looked at that code. I gave you my best guess of what’s going on from your problem description and recommend you look at the API and see how you can feed framebuffers and do swapping between 2. I do not know/remember off hand how it works