Lightweight graphical browser comparison

[peterc]

Well, I tried links and w3m, and decided that today's web is better viewed graphically--your opinion may differ, but that is my own. So the next question was, "What's a good lightweight graphical browser?" I looked through the extension list and decided to try three: Arora, Opera10, and Midori. Here are some statistics that others may find interesting.

Physical size:
Arora + dependencies: 15.8MB
Opera10 + dependencies: 19.4MB
Midori + dependencies: 32.8MB
(Physical size was determined by running 'base norestore', installing a browser, and running 'du /tmp/tce/optional'.)

Memory usage:
Arora + dependencies installed, not running: 9.9MB
Arora running: 102.8MB
Opera10 + dependencies installed, not running: 24.5MB
Opera10 running: 86.4MB
Midori + dependencies installed, not running: 58.6MB
Midori running: 96.1MB
(Memory usage was determined by running 'free' on three occasions: immediately after booting into 'base norestore' for the base level, immediately after installing the extension, and then immediately after starting the program. To determine the memory required for an installation, I subtracted the base level from the amount recorded after installing the extension; to determine the running memory, I subtracted the base level from the amount after running the program. Tell me if there's a better way.)

Observations: For the smallest physical size, Arora is the way to go. For the smallest amount of memory used, Opera is the way to go. Midori seemed as thought it would be a bloated pig after I installed it, but surprisingly, its memory usage only 10MB more than Opera and 6MB less than Arora.

No conclusions yet; I still need to try them out for a while. More later?

Edit: by request, here are the figures for Chromium:
Chromium + dependencies, physical size: 31.7MB
Chromium + dependencies installed, not running, memory usage: 49.5MB
Chromium + dependencies installed, running, memory usage: 125.2MB

[jur]

Would be very interesting to have chromium in there as well.

[Arslan S.]

here are my candidates for first place
http://www.uzbl.org/ (based on gtk+/webkit)
http://conkeror.org/ (based on xulrunner/gecko)
http://dooble.sourceforge.net/ (based on qt/webkit)

[peterc]

here are my candidates for first place
http://www.uzbl.org/ (based on gtk+/webkit)
http://conkeror.org/ (based on xulrunner/gecko)
http://dooble.sourceforge.net/ (based on qt/webkit)

Well, as soon as they are available in the repository, I'll try them. First time I've heard of dooble, though--maybe I'll look into that a little more.

[peterc]

Would be very interesting to have chromium in there as well.

Done. Edited the original post to add the results for chromium.

[blofsy]

Try "links -g". Memory usage is ~ 9 MB. No flash and bloatware support.

[tinypoodle]

links -g is using ~ 5 MB RES mem here. Perhaps ~ 9 MB is VIRT mem??

Either way, I doubt any other graphical browser could compete with links what concerns speed and memory usage, and not many can match the stability of links either.

Unfortunately the extension available in repo appears to be compiled without any other graphics support besides from X. (Does anyone have any idea why that is so??)
As links is lacking a "tabbed browsing" feature, it can get messy under X when having
to open many windows concurrently. However, when running links in graphics mode on a tty - e.g. with framebuffer or svgalib driver - it can create up to 10 virtual consoles which more or less equals/replaces the functionality of "tabbed browsing".

other possible candidates:

- dillo(2) available as extension (fltk based)

- hv3 available as statical binary from http://tkhtml.tcl.tk/hv3.html (Tcl/Tk based. Hasn't
  been updated since nearly 2 years but can be quite valuable, particularly for its CSS support)

(Memory usage was determined by running 'free' on three occasions: immediately after booting into 'base norestore' for the base level, immediately after installing the extension, and then immediately after starting the program. To determine the memory required for an installation, I subtracted the base level from the amount recorded after installing the extension; to determine the running memory, I subtracted the base level from the amount after running the program. Tell me if there's a better way.)

do a <sudo cache-clear> immediately before each time of measuring memory.

[Jason W]

Is if framebuffer support that you are saying is missing from links2?

I will rebuild it with "--with-fb" since that would be a good feature to have.

[tinypoodle]

Is if framebuffer support that you are saying is missing from links2?

Yes

I will rebuild it with "--with-fb" since that would be a good feature to have.

Excellent, thank you!  
I think amongst other this might also be of benefit to some who are running microcore without X.

NOTE: In order to compile/run links2 with framebuffer support, gpm - which i haven't seen to exist in repo of TC - is a requirement/dependency. There is a patch for gpm included in links2 to support graphics mode for smoother cursor movement, but that's not an absolute requirement. (IIRC gpm is only required to provide a cursor for links2 with framebuffer support, but not for svgalib support).

[Jason W]

gpm uploaded,   I will aim for links by tomorrow if time allows.

[Jason W]

Yeah, "links -g" when in console session in framebuffer with gpm is neat indeed, and simple to start.

I will be uploading shortly.

[tinypoodle]

There is now a script which determines size of an extension including deps in a painfree and accurate way: http://forum.tinycorelinux.net/index.php?topic=6863.msg36061#msg36061