9.1.2 Observation - LocalUI.Service

[Tim Curtis]

No noticeable performance impact on my machine. As Kent mentioned, disabling GPU removes the "tearing / flickering" that was sometimes seen with it enabled
I guess a performance hit might be more noticeable if video playing or 3D rendering was involved, but very little impact when loading a simple web page.

Try selecting the "Animated" backdrop style under Prefs > COVERVIEW

[2800GT]

I'd never tried the animated backdrop before - just tried it and it seemed slow and jerky so I removed the disable-gpu option and restarted.
The animation still seemed slow and jerky so maybe thats as good as a Pi 3 can do.
I am still running the animated "now playing" waveform and that seems to cope.

[Tim Curtis]

I'd never tried the animated backdrop before - just tried it and it seemed slow and jerky so I removed the disable-gpu option and restarted.
The animation still seemed slow and jerky so maybe thats as good as a Pi 3 can do.
I am still running the animated "now playing" waveform and that seems to cope.

Ok good info. The EQ animated icon typically pushes CPU utilization up quite a bit for example 60% vs 5% with just the static waveform icon.

[2800GT]

I'm pretty much in the same place as Kent - I confirmed the chromium roll-back procedure worked and am back on build 126 but I'm leaving the --disable-gpu in place as the local interface is much more "stable".

However, I still can't enable "Log to RAM" without losing the local display. 
As far as I can tell as soon as I enable it and reboot the software can no longer detect an attached DSI display during boot.
My display is not the official 7" DSI by the way  

I just fired up my Pi to try the 9.1.3 update and noticed the Log2RAM was enabled and my local display was working.
No idea when I re-enabled Log2RAM and why it isn't killing my local display anymore but fingers crossed it still works after the update.

[Tim Curtis]

I'm pretty much in the same place as Kent - I confirmed the chromium roll-back procedure worked and am back on build 126 but I'm leaving the --disable-gpu in place as the local interface is much more "stable".

However, I still can't enable "Log to RAM" without losing the local display. 
As far as I can tell as soon as I enable it and reboot the software can no longer detect an attached DSI display during boot.
My display is not the official 7" DSI by the way  

I just fired up my Pi to try the 9.1.3 update and noticed the Log2RAM was enabled and my local display was working.
No idea when I re-enabled Log2RAM and why it isn't killing my local display anymore but fingers crossed it still works after the update.

Interesting. Was it off b4 the update?

[2800GT]

Yes, before the update.
I decided to download the startup log before doing the update in case I wanted to compare with startup after updating and noticed Log2RAM was enabled.
I've no idea what changed between 10/10/24 and today but when I wrote that post on the 10th I had tried enabling Log2RAM multiple times, and each time the local display service would not display so I thought I had left Log2RAM disabled.

I'm now running 9.1.3 with Log2RAM enabled and the Chromium --disable-GPU set and all is still good

[TheOldPresbyope]

RPi 3B+ / Official 7" Touchscreen

Fresh install of moOde 9.13 (e.g., Log2RAM is enabled)

The local display still lacks the roundels in the Playback view. The screen breakup when changing from Playback view to a Configuration view remains but perhaps it's not as severe. The bleed-through of the Playbck view randomly occupies anywhere from none to 30 percent, say, of the screen and keeps showing up and then disappearing. Subjectively, I think it is less disruptive than before but that may be wishful thinking.

DIsabling the GPU in the Peripherals view seems to suffice to fix both problems whether Log2RAM is enabled or disabpled.

Note - I just discovered this afternoon that there is a more specific chromium switch which seems to suffice.

Try 

--disable-gpu-compositing

instead of

--disable-gpu

I don't know what the difference is---they may well be equivalent in terms of the moOde webUI---and I have only of few hours of testing under my belt. 

As always, YMMV.

Regards,
Kent

[2800GT]

Done
https://github.com/RPi-Distro/chromium/issues/50
Hopefully it makes enough sense

On the RPI-Distro chromium github they advise they need a way to replicate this in the standard Raspi OS.
Not a queston I can answer (I only use software, I don't write it)
As the local display is using the chromium browser I assume the display is some sort of html web-page with fixed elements that are populated when the page loads and dynamically "drawn" components like the playback progress and volume slides that update ?

[Tim Curtis]

Our OS images are actually made with Pi-Gen the same tooling thats used to make the official Raspberry Pi images. In fact you can just install the moode-player package on an official RaspiOS Bookworm Lite. The only difference would be some of the specific package versions that we use and two patched kernel drivers.

I'll respond to the issue.

[Tim Curtis]

Regarding the Git issue
https://github.com/RPi-Distro/chromium/issues/50

@XECDesign proposes trying a generic repro.

Code:

1. Flashed the lite arm64 image and booted on a 3B with a DSI display
2. Installed xinit, chromium, openbox and xterm.
3. Added a .xinitrc file to run xterm & openbox
4. Ran startx and launched chromium from the terminal window

Tried a few sites and everything rendered as expected.

Maybe someone could try this and see if any moode rendering issues appear.