Chromium on Pi2

Doesn't chromium render in GPU? And the Pi2 would have pretty basic specs/ low VRAM (or shared with system). So going to guess that's the reason? Install a tool ("like" HTOP) but for monitoring GPU, that'll show it :)

How much RAM do you have? Is it massively swapping to slow SD card?

If you're using htop, it won't show kernel threads unless you're press F2 for setup and then unselect Display options -> Hide kernel threads.

Theo

I found out that pure debian does not perform so good as the raspi version. Are you using debian or raspi ?

I never tried UI on the RPi2, but found out that raspi version provides some optimizations that are missing in native debian for RPi4.

may be this will help

If the system runs low on RAM, Linux wakes up its dreaded “OOM Killer” kernel thread to free up RAM by killing the most memory-hogging processes. You will see evidence of this happening in the logs. If Chromium loses a process or two, that might indeed bring operation to a screeching halt (though I would expect to see it display error messages as well).

This is a Pi2, so 1 gig RAM. I've not messed with the CPU/GPU memory allocation, it's default AFAIK. A quick look at Task Manager suggests less than half a gig of RAM in use, htop reports the same with 100M of swap in use out of 500M available. This is on a somewhat elderly microSD in a default image as distributed from the Raspberry Pi website.

The task manager is also reporting 0% cpu for all the chromium processes. That's rather odd. At the moment chromium is trying to re-open its window after being iconified and it's making no progress. After a couple of tries the "close window" (top right x) got rid of the window.

There are also two "chrome_crashpad_handler" processes, 0% cpu. Might that be a hint chromium has crashed, and the handler that generates the "aw snap" dialog crashed too?

thanks for reading!

bob prohaska

chromium --disable-gpu

Then everything will run only on CPU and HTOP will tell the real story, you'll likely have heaps of threads spawn, and some idea what it's doing (less hidden then when GPU is processing).

Have you tried falkon (lighter weight QTWebEngine based Chromium - KDE project work) or iridium (stripped out Google BS code version of chromium)? Do they load the page you're trying to get?

Disabling the GPU leads to broadly the same behavior, but I'll have to watch for a while to be sure. I don't think it's an improvement 8-(

Looks like neither is available for 32-bit RaspiOS. There does seem to be a 64-bit version of Falkon available, I'll try that on my Pi5:

At the moment the "loading" icon is spinning with a tab label saying data:text/html;charset=U and falcon:start in the URL bar...nothing more. Doesn't look very promising....

Thanks for writing!

bob prohaska

When the Pi 2 came out I did do a little web browsing on it. It wasn't fast then, but it did work. However that was 10 years ago, and web pages have got far bigger and browsers fatter and slower, which very much conspires against the meagre 1GHz and 1GB of the Pi 2.

The Pi 3B/3B+ is a tiny bit quicker at 1.2GHz and 1.4GHz, but still limited to 1GB of memory, so web browsing isn't appreciably better. Even with a just few simple google chart based status pages, it is very slow to update.

The Pi 4B with at least of 4GB is the minimum practical spec for web browsing. The Pi 5B with 8GB is pretty nippy, and comparable to my 10 year old Intel laptop running Mint.

--druck

Have a look at the size of the executable "then" (which is more likely to be 20 to 25 years ago) and now, and you'll see why a 512M Zero 2 doesn't stand a chance.

---druck

webkit webprocess is over 1GB on this machine now. Firefox process another 800MB

Thunderbird another GB or so. I buckled and now have 24G RAM.

No it really was only two or maybe three years ago and Firefox wasn't that much bigger then.

The Executable still fits easily in 512MB RAM, for some reason it tries to allocate lots more RAM after starting and displaying the browser window (which seems to work fine for a few seconds before it stalls).

It seems the RAM usage increased when they started using multiple processes:

There is also the issue that many modern websites are running memory gobbling Javascript implementations

That idea was pioneered by Chrome/Chromium, I believe, as a way to improve both security and robustness.

Other browser developers eventually realized that, in spite of the increased resource usage, it was the right thing to do.

Blame that on Google, for pioneering the “V8” JavaScript implementation that greatly sped up its execution speed. Prior to that, JavaScript was only good for adding limited interactivity to web pages. But suddenly, it became feasible to add enough code to approach the full complexity of a locally-running app -- and all entirely in the browser.

That massive leap in performance also led to JavaScript becoming usable for back-end development, with nothing to do with browsers at all. Hence the inception of NodeJS.

Upgraded from Firefox 140 to 141 on the Pi Zero 2 and it's working much better. Loads old-fashioned sites fine (though very slowly) and some modern ones if their Javascript is blocked. With JS or just big webpages it often gets stuck though.

Weirdly the User-Agent header it sends out says x86_64 though it says AARCH64 within the browser. Seems it's unwise to be honest about using ARM when talking to some web servers:

If you want to determine the capabilities of the client system, checking the user-agent seems a pretty naïve, not to say dumb, way of doing it.

It would be better to do a more directly functional check.