Chromium slow on Beaglebone black

Hi,

I’m working on an application with Beaglebone Black where I will use a Newhaven LCD cape as a display for a local web server (Codesys webvisualization). I have installed the latest debian console image and configured lightdm/openbox to autostart a browser and connect to the server.

I first tried with Chromium that opens nicely in kiosk mode, but the update of the display is painfully slow. There are some animated buttons, and when I press one it takes about a second before the GUI changes. If I open google.com instead of the local server and use the keyboard to type in text it also takes almost a second before anytging happens on the LCD.

I then tried with Midori. I did not manage to get Midori to open in full screen kiosk mode, but what I can see the update is equally slow.

The options I use when I start Chromium is:

chromium \
--no-first-run \
--disable \
--disable-translate \
--disable-infobars \
--disable-suggestions-service \
--disable-save-password-bubble \
--start-maximized \
--kiosk "http://localhost:9090/webvisu.htm" &

Are there any configuration I have missed that can speed up Chromium, or are there alternative browsers that can be more responisive? What puzzles me is that when I use top from the console the total CPU load and used memory is below 50%.

Rgds
Gunnar

Hi @gunstr Chromium has really become slow on Single Core processors… I’ve personally had better luck with Firefox lately…

Regards,

Hi @RobertCNelson Thanks for the suggestion.

I have now also tested Firefox. The observation is that it takes far longer time (>5min) to load the web visualisations during initial boot than Chromium / Midori (~1min) and once loaded the response time is similar across the three.

To further isolate the problem, I added a text box to the web page and when I type it takes close to a second after pressing a key until the text box is updated. Then I installed a lightweight text editor (FeatherPad ) and run that instead of the browser. Then the response to a key press is with no visible delay at all.

My conclusion is that the problem is related to the browser, and as I have now tested three alternatives all having the same behaviour I tend to think this might be a dead end. One option I see is to use a separate Raspberry just for the display. Will add more hardware but would give me a system with better response.

Any other suggestions are welcome.

Regards

Yes it is slow. Alot of overhead for single core processor.

Have you looked at BeagleBone AI to get more GUI performance?

It’t been awhile but I thought RCN had an earlier version of chrome that you could install and lock down.

After installing the earlier version of chrome it would run and not crash.

Am sorry I can not remember the version but it did run with a vnc session into the Beaglebone.

Perhaps RCN could shed some light on this.

Ken

We have version 67.0.3396.87, but i’m pretty sure some sites will say it’s “too” old…

https://rcn-ee.net/repos/debian/pool/main/c/chromium-browser/

Regards,

Perhaps jkridner will read your reply. Thanks.

Ken

Thanks a lot for your input. For this project I actually found some other advantages by splitting up the system. So a BeagleBone Black will run as a headless sever, and I will use a Raspberry for the display running Chromium.
@jkridner, the BeagleBone AI looks interesting, will for sure consider that board for next project.
Rgds

Hello,

Can you explain me how did you do it?
I need the same thing that you have done.

Thanks.

Hi,
Which part of the solution do you refer to? Running Chromium on BBB or the Codesys controller?
Rgds

Running Chromium on BBB. Beacause i install the debian 10.4 LXQT imagen flasher and the system and the codesys webvisualization are very very slow.
what image are you using?

thanks.

hi @adrianpablos retry with running Firefox, Chromium is becoming just un-usable for a single Core SBC…

Regards,

Hi @RobertCNelson Can you recommend which image to use for this project?

Regards,

Nope i can’t… Chromium really taxes the Single Core, you can try “firefox” in the image your currently using… Or any other light weight Web Browser… The problem, web browsers are not simple “displays” any more, instead they have become their own multi-headed beast of an application…

Regards,

Hi,
I can just confirm what @RobertCNelson wrote. As I mentioned earlier in this thread I actually tested also two other more “light weight” browsers but eventually gave up on having both the server and the browser running on the BBB. I separated the two and is no running the Chromium browser on a separate Raspberry Pi 4.
Rgds