Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Python 64x64 expected performance #710

Open
tohox opened this issue Oct 28, 2018 · 1 comment
Open

Python 64x64 expected performance #710

tohox opened this issue Oct 28, 2018 · 1 comment

Comments

@tohox
Copy link

tohox commented Oct 28, 2018

Hi,

I'm using a 64x64 matrix (the one sold by Adafruit) with their bonnet to display cycling animations. I'm doing this using Python 2.7 both on a PiZero W and Pi 3B+ although I would much prefer to use the PiZero for space concerns. I'm using PipaOS 6 a lightweight variant of Raspbian Stretch in both cases.

I'm cycling though 64x64 PNG images with transparent backgrounds approximately 30 times per second using the CreateFrameCanvas() and SwapOnVSync() technique. While the image refresh rate is just barely sufficient on the Pi Zero it appears smooth on the Pi3B+ but on both boards I get noise consisting of horizontal lines flashing in random positions which I don't get at all when running the C++ demos (on either board). When I set show_refresh_rate to True in my script I get approximately 80Hz on the PiZero and about 130Hz on the Pi3B+. Top shows about 70% CPU usage on both boards while the script is running.

Does this correspond to expected performance when using Python or am I doing something wrong? Should I revert to C++ to get perfect playback?

Raspberry Pi Zero W video
Raspberry Pi 3B+ video

Thanks!

@hzeller
Copy link
Owner

hzeller commented Oct 28, 2018

Problem is that Python has garbage collection, so will have a much higher memory throughput that you can't control from the language; unfortunately, the memory bus on the Pi seems to be pretty limited, so if there are many things competing for the memory bus, you will see issues. I suspect part of this is what you are seeing. Using CreateFrameCanvas() initially and then doing SwapOnVSync() sounds like is already the best you can do, as you minimize any additional unnecessary allocation.

What you definitely want to do is to use the hardware PWM hack (needed for both the Adafruit HAT and Bonnet) https://github.com/hzeller/rpi-rgb-led-matrix#improving-flicker - it will almost eliminate the flashing lines issue. You will still get some overall brightness fluctuations, but much less pronounced.

In general, I recommend using the Pi3, as it has four cores, of which you can use one entirely for the display update (using the isolcpus=3 setting described in the README).

On the PiZero devices, you only have a single core which is equivalent to the Raspberry Pi 1 so about factor 10x slower.

Python is pretty slow, in particular on the PiZero type boards, but since you use prepared frame canvases which are mostly a thing handled on the C++ side, it is probably not as problematic. But you still have the overhead of Python garbage collection and possibly other parts messing with the system-speed.

In general of course, C++ is recommended if you want the best speed. You can also use the ready-made LED image viewer if it is sufficient to just display canned animations. But as usual it all depends: if things are 'good enough' with Python, this might be already sufficient.

I suggest to proceed like this

  • Use the PWM hack to minimize/eliminate the white glitches.
  • The remaining flicker, you might reduce with the FIXED_FRAME_MICROSECONDS setting. It is a compile-time option, so you have to go through the whole compiling the library and Python binding for this. It also will reduce the frame rate. So if you already have only 80Hz on the Pi zero, it will start flickering noticeably.
  • In general, a Pi3+ is probably a good choice for the better CPU and somewhat acceptable frame-rate.
  • If everything is still annoying, then using C++ and the content-streamer interfaces are probably a good level up.

hzeller added a commit that referenced this issue Mar 18, 2020
… on loaded system.

This used to be a compile-time option FIXED_FRAME_MICROSECONDS but
it is very useful to tweak at runtime.

Issues #276 #458 #467 #478 #483 #495 #551 #556 #571 #626 #651 #710
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants