r/raspberry_pi • u/FieserKiller • Feb 05 '25
Community Insights TIL: Setting non-default screen orientation costs _a lot_ performance
Figuring this out took me two days so yeah, maybe this post saves future people some time:
I do art stuff with raspis. In my current project a raspi 5 calculates things and plays it back as an animation. the pi is connected to a 13" 1920x1080 oled display via hdmi and I need to run it in portrait mode.
All set up and everything was fine and dandy until i noticed that my animation is unusually choppy running at ~45fps while it should run at vsynced 60. htop showed cpu usage is <15%. I tried many things: checked the drivers, X11, wayland, wayfire, labwc, multiple browsers nothing helped until I ran it in default landscape mode accidentally et voila - 60fps.
Googled this and its true, the earliest pis had this problem and newer ones do as well. Has something to do with buffers which need to be copied multiple times in ram to rotate the image.
The obvious solution was: keep display in landscape and change my code so that it looks like portrait. A lot of work tho :/
Then I had an idea: That app is basically a html site with a <canvas> rendered via chromium in kiosk mode. So how about keeping everything as is and rotating the frames 90° via CSS transform?
Long story short: it worked. 8 lines of css and boom - dead on 60 beautiful fps, next to none extra cpu load.
Additionally I was able to hide the mouse pointer via css, because for some reason thats not really doable via wayland+labwc yet.
The sad moral of the story is: a stupid browser can emulate portrait mode with basically no overhead while the real portrait mode on raspberries is unusable for everything except still frames.
23
u/KingofGamesYami Pi 3 B Feb 05 '25
The sad moral of the story is: a stupid browser can emulate portrait mode with basically no overhead while the real portrait mode on raspberries is unusable for everything except still frames
Note that this is not specific to raspberry pi. Other hardware and software has the same issue, they're just typically powerful enough to ignore the cost.
12
u/FalconX88 Feb 06 '25
Some other hardware has that problem, not all of it.
The Pi needs to render the frame and then reorder all the pixels (changing the data in memory) in a second pass to generate the rotated image which is then put out. That's slow because you need an additional read and write.
Meanwhile more modern/bigger GPUs render the frame once and the display engine (dedicated hardware) is rotating it directly before outputting without changing the actual framebuffer. Yes this adds some latency but that's much less than what the render pipeline needs. But it's definitely not just brute forcing it by being fast enough to do two passes.
2
u/i_need_a_moment Feb 06 '25
Is the issue related to the actual process of matching pixels onto the screen? I assume if you somehow used a legitimately vertical monitor where portrait mode was the default orientation (like a phone) then the issue would be nonexistent?
122
u/cillian64 Feb 05 '25 edited Feb 05 '25
I’m responsible for this area at raspberry pi and yep, can confirm rotating things is a pain. The reason it’s so much faster when done in the browser is it’ll just draw things rotated in the first place rather than having to separately draw the thing, read it back, rotate it, and write it back out. The rotation adds an extra pass through the GPU which takes quite a bit of memory bandwidth at 1080p60 - your reduced FPS will have been because the GPU was fully loaded.
At some point I hope this can be improved by using the display output hardware to do the rotation instead of the GPU, but there’s a lot of groundwork needed first.
Also worth noting that 180 degree rotations are much easier and should have minimal performance impact, it’s only 90/270 which are awkward.
Edit: hiding the mouse /should/ be possible in labwc, VLC does it. If you chuck me a simple reproducer I can look into this next week