On a Model B 512 MB Pi with Raspbian “wheezy”, I have tried Midori, Chromium and Iceweasel. When the web page gets larger, loading is slow, even after I overclocked it to 1 GHz. On an Android phone with a 1 GHz CPU, the web page loading seems much faster.

What I want to know is, where's the bottleneck in the Pi? Is it the CPU, or RAM size, or unaccelerated X server? Is it possible for the browser to use GPU directly in order to speed it up?

And the pi is driving a 3.5" 480 x 800 screen? ;) If not perhaps that alone is a bit of a factor...
–
goldilocks♦Feb 24 '13 at 23:42

A VGA monitor is used for display, through a HDMI-to-VGA cable, and config is hdmi_mode=35 1280x1024 60Hz ... But I can't see any improve after changed the config to hdmi_mode=9 800x600 60Hz
–
hello.wjxFeb 25 '13 at 5:56

No doubt. I think tapped-out has the correct answer to this question but I added another one with an idea for you.
–
goldilocks♦Feb 25 '13 at 14:25

3 Answers
3

It's a combination of the Raspberry Pi's fairly weak ARM11 CPU and the unaccelerated X server. Since it's not accelerated by the GPU, the CPU has to do all the rendering; on something like the ARM11 core in the Pi, this puts a lot of extra strain on an already weak CPU.

Anecdotally, while watching htop while Midori on the Pi loads a heavy website like Facebook, I've seen the X process take up to 25% of the CPU.

It's not really fair to compare the chip in your Android phone to the chip (even overclocked) in the Pi. The 1 GHz chip in your phone is probably something like a Cortex-A8 or A9, which use the ARMv7 version of the architecture; thus, they are higher performance per clock cycle than the ARM11, which uses ARMv6.

Tapped-out already answered this, and what I am suggesting will not make much difference in this case, but it might be useful to know.

If all you want to do is run the browser, you don't have to run a desktop environment as well. Create a file which looks like this as $HOME/.xinitrc:

#!/bin/sh
midori

If .xinitrc already exists, move it temporarily or comment out anything else. Now, startx (obviously, you should not be in it already -- do this from the console without the GUI running). Voila, you have just the browser, no desktop.

That saves a wee bit of memory, although the browser is by far the elephant in the room and the Xorg server itself (that's running) is bigger than a basic lxde (which now isn't running). If you have so much loaded into RAM that you are using swap, that will impact performance. The above midori + bare X uses < 100 MB resident according to free:

That's with 4 tabs open. Again, if you look at these and see your RAM is near full, that's a performance issue. Note that it is normal to use a bit of swap even if the ram is not full, so don't worry about that -- that swapped stuff is low priority.

Something further to think about, performance wise, is the significance of buffers and cache. I did not include these in the total, and notice it is actually more than the committed memory (about twice as much). That is normal. If you fill the memory up with committed stuff, the system will just use less cache and/or transfer it to swap. Either way, that is going to be a performance degradation because the cache is important (it's just not vital or immutable size wise, so not part of the committed mem stat).

In other words, optimally you want your committed ram to be no more than 75% of what's available on the pi and perhaps less than that. If you use LXDE and start opening other stuff, you may quickly start to approach that.

Forcing GPU acceleration in by enabling "Overrrite Software Rendering List" will use the GPU for rendering at the cost of possible artifacts, even if the driver is not whitelisted. I do not know how well this works with the Pi's GPU, though.

GPU compositing on all pages will use the GPU to scroll all layers. So scrolling performance should improve on pages without GPU-accelerated layers.

Refresh window tilewise would be another hint. It will render tiles and display each as soon as it is ready instead of waiting for the last one to finish. In effect rendering will take longer due to the introduced overhead, but content will appear faster.

Rendering in separate thread will do the rendering asynchronously and keep the interface responsive. You can scroll while the page is still rendering.

Disable GPU VSync will update the rendered contents regardless of whether the monitor has loaded them yet. This improves the frame rate at the cost of inconsistent presentation.

After enabling/disabling any switches, you will have to restart Chrome/Chromium for the setting to apply. The button at the bottom of the flags-page can do that for you.

I tried flags Override software rendering list, GPU compositing on all pages and Threaded compositing on Pi, but there seems no apparent improvements. I alse tried those flags on PC, seems no improvements, too.
–
hello.wjxFeb 27 '13 at 4:44

Make sure to restart Chrome after editing flags. To test Override software rendering list open a WebGL demo. To test Threaded compositing try scrolling while a big page is still loading.
–
BengtMar 1 '13 at 15:37

From what I'm reading here: chromium.org/developers/design-documents/… using "Threaded compositing" won't help on the pi -- it only has one core -- and may make it worse, depending on how significant "operat[ing] on a copy of the current rendering state" is.
–
goldilocks♦Mar 5 '13 at 13:29

The page load performance will decrease, yes. But Javascript will not block and wait for rendering and the page will stay responsive. You are trading some objective performance for some perceived performance.
–
BengtMar 5 '13 at 18:12