Firefox Granparadiso + Patch and tweak

[Gavin McCullagh]

Hi,

On Thu, 20 Sep 2007, Jim Kronebusch wrote:

> Excellent summary Gavin.  I have to admit I don't know how to implement
> any of the suggestions, at least not yet.

It would be interesting to see what effect the overcommit_memory setting
has.  If you can set the root password in the thin client chroot[1], you
can boot a thin client, press <ctrl><alt><F1>, login, type:

	echo 2 > /proc/sys/vm/overcommit_memory

logout, press <ctrl><alt><F7> and see if the system still locks up on those
webpages with the original firefox.

[1] https://help.ubuntu.com/community/EdubuntuFAQ#head-285f03d2d3ed2f29847c7793dbdb8f1488814c1b

> I did receive a shim code from Brian Paul last night that can be
> preloaded and does effectively monitor pixmap usage and kills the
> offending app if it exceeds a pre-set limit.  

That's interesting.  I guess a more advanced one would kill it if it
approached some percentage of the total available.

> I just can't believe that as large of a problem this seems it could be/is
> that there isn't more discussion on it.  

It's really only a visible problem on low RAM machines like thin clients.

> Since it appears this really could be a possible fix for Firefox, it
> would be nice to improve it and not use a hard set limit.  I asked if it
> was possible to code this section to monitor overall RAM usage, and set
> the limit accordingly.  Say if RAM usage is less than 15% set the discard
> timer at 10 seconds, if usage is at 50% set it to 5 seconds, if at 80%
> set it to .2 seconds.  This may not be at all feasible, but if it is,
> this could provide increased speed and performance as intended on systems
> with plenty of RAM, but on lower RAM systems or where RAM use becomes
> heavy, the discard timer would self adjust and sacrifice performance for
> stability.  We'll see what he posts back.  

On a regular desktop, this might be workable, but it almost certainly isn't
on thin clients.  Firefox is running on the thin client server and the RAM
usage issue is on the thin client.  The only component which runs on the
thin client (and is therefore able to look at ram usage) is the X Server.

I suspect a patch for Firefox to turn off pixmap caching, or limit the
amount of it, would be better.  If Konqueror and Opera don't need to behave
like this, I don't see why Firefox should.  

One rider to this though.  It might be curious to compare the network
bandwidth usage of firefox with that of the other two, while scrolling your
test page up and down.  The suggestion made by Carsten and Glynn was that
there is a balance between using pixmaps and ximages and that the latter
could cause very high bandwidth usage as the data gets shuffled to the
client every time it needs repainting.  If Konqueror and Opera do this,
they may cause other issues for thin client networks.  Perhaps the firefox
approach is better for us, but just needs to be tuned.

	http://lists.freedesktop.org/archives/xorg/2007-September/028490.html
	http://lists.freedesktop.org/archives/xorg/2007-September/028478.html

I had always naively thought that a browser, when given a large image and
told to display it smaller, resized the image before displaying it.  This
is apparently not true of firefox.  I wonder if it is for the others.

> I have also not received word yet on the possibility of a backport for
> this patch to 2.x.

This would be cool alright.

Gavin