-
One of the things we want to do about GNOME bugs in openSUSE is to have "bug topic days" or weeks, where we take care of all the bugs in a certain category. Brady Anderson came up with this idea, and it's great! Fix everything related to having multiple screens. Fix any potholes in the photo workflow. Fix everything related to the clipboard (oh my god, that may need more than a week...).
Do you have a multiscreen setup and have found bugs in the way GNOME deals with multiple screens? Let us know!
-
Owen beautifully describes what we need to do to make it easier to make experiments with the GNOME code base.
-
The GNOME sysadmins have been busy working on Mango, the new system to request GNOME accounts. This has been a very sore point in our project; we don't want new contributors to go through an opaque and seemingly bureaucratic process just to be able to get code into GNOME. I'm delighted to see Mango happen. Thanks to all the people who worked on this!
-
Today we had a very productive public meeting for the openSUSE GNOME Team. We are building a plan around which bugs to fix first, how to track patches that are specific to openSUSE vs. those that should go upstream, and how to make it easy for people to package GNOME software for the GNOME:Community repository in the build service.
-
If you are using openSUSE 10.2 and you have trouble with Nautilus using 100% CPU when mounting/unmounting drives, then use this package which contains the fix!
-
Photo of Japanese APF photographer being shot by a soldier in Myanmar (source).
-
Marcel Marceau is dead. Oralia and I had a chance to see him perform in Xalapa a few years ago; definitely an inspiring sight.
-
I just got mail from my good friend Paco Becerra, who is getting married! This is great news.
-
I've moved my activity log and web page from primates.ximian.com to www.gnome.org. Please update your bookmarks. For me, this makes it easier to sync instead of going through any number of ssh tunnels and VPNs.
-
Joe talks again about the stupid password policy at Novell. Personally I use the l33t-speak version of verses of a well-known song from an advertisement in Mexico. I move forward one verse with each password change, though I had to skip a verse or two when the new password wasn't good enough for the "must have at least three different characters from the previous password" policy.
-
Philip asks how to remove people you don't like from your display of Planet GNOME. I just created a wiki page on how to remove bozos from Planet GNOME, based on Johan's excellent tip. The instructions are for Epiphany and Firefox.
-
I've just written a little guide on Git for GNOME developers. Use it to learn how to use Git and Git-svn to interact with GNOME's Subversion repository.
-
Smaller footprint for images in Firefox, part 2
Previously: Part 1
I fixed the JPEG loader, so Firefox can now discard both JPEG and PNG images after a few seconds of inactivity. This is the net memory savings for a bunch of web pages:
For example, Firefox with my patch uses about 27 MB less memory than an unpatched one when viewing BldgBlog, which uses tons of large images.
And here is a breakdown of those values. As usual, pixmaps live in the X server and RSS is for the Firefox process itself.
You'll notice that pixmaps go *way* down, while RSS goes up by a smaller amount. This is because the patch makes Firefox keep the compressed data for images instead of the uncompressed pixmaps.
Why keep that data around in memory, when Firefox already has a disk cache with that data? Because right now image containers in Firefox don't know where they came from: an image container does not have a URI property to say, "if I ever go away, you can recover me from here". An improvement to the patch would be to annotate image containers with their source URIs. When the images get uncompressed on demand, Firefox could then look in its disk cache to get the data for an image's URI. This would shrink the memory requirements even further.
Finally, this is the total memory usage for an unpatched and a patched Firefox. This is not just the memory used for web pages on top of Firefox's basic footprint; this is everything: code, data, images, etc.
As usual, the Git repository is here:
git clone http://www.gnome.org/~federico/git/mozilla git checkout --track -b timeout-image-discard origin/timeout-image-discard
Current patch: moz-images-20070907.diff.
Bug: #296818.
I'd say this patch is good to go. It would be nice if someone with experience in benchmarking Firefox could give it a try :)
-
My patch to make Firefox use less memory for images now also supports the PNG loader. I discovered some problems with the JPEG loader, which have to do with images that get loaded in very small chunks — will fix that tomorrow. In the meantime, you can play with this:
git clone http://www.gnome.org/~federico/git/mozilla git checkout --track -b timeout-image-discard origin/timeout-image-discard
Current patch: moz-images-20070906.diff.
-
Git for computer scientists is a pretty damn good explanation of how Git represents a repository internally. Now "git fetch" and "git merge" make sense — up to now I didn't grok how the repository could contain changes that are not in my working tree.
-
Smaller footprint for images in Firefox, part 1
When you load a web page with images into Firefox, the browser downloads the images, uncompresses them, and converts them to pixmaps which it can paint onto a window. Firefox keeps these pixmaps around for as long as you view the page or have it in a browser tab, and for a little longer for its back/forward cache (and probably for other places in the code that reference the pixmaps as well).
Storing images as pixmaps is wasteful for various reasons. Pixmaps use a lot more memory than the original (compressed) image data; in fact they may be larger than plain RGB data, since pixmap data needs to be padded to accomodate what the X server needs. Also, the X server is not very smart about moving pixmaps around in memory. If you are lucky, these pixmaps will live in video RAM — but they'll make room scarce for more important things, like temporary pixmaps for double-buffering. If you are unlucky, the pixmaps will end up in system RAM and may eventually cause more important things to get paged out.
A long time ago I wrote a toy program to see if uncompressing images on demand would be slow. Ideally, Firefox should only generate uncompressed image data when it needs to paint the image. If you switch tabs or scroll away, those images should disappear from memory. My little program showed big savings in memory, and little loss of performance due to uncompressing the images repeatedly.
I've finally gotten time to actually implement this for Firefox. The scheme is this:
-
Firefox downloads an image from the net.
-
The original compressed data gets saved in memory. The image gets uncompressed into a pixmap, and a timer starts up.
-
When the timer fires (after a few seconds), the uncompressed data in the pixmap is freed.
-
If the data needs to be accessed again (say, to repaint), it gets uncompressed and the timer is started up again.
This is a chart of how much memory Firefox uses, in terms of RSS as reported by pmap(1), plus pixmaps as reported by xrestop(1). The idea is, "show me how much memory I have in the Firefox process, plus how much memory it uses in the X server".
Here's the patch against Alpha 7 of Firefox 3: moz-images-20070903.diff.
A few caveats:
I haven't tested the patch extensively yet. Things seem to display fine. A few pages "lose images" after a while (especially photo.net).
This is implemented only for the JPEG loader. The code to do it for the PNG loader should be straightforward, and similar to the JPEG one.
Likewise, the GIF loader doesn't have the necessary code yet. I'm sure this will uncover bugs in the way I handle animations inside image containers.
Even when implemented for all the image loaders, I'm afraid this won't save much more memory. Firefox has a *lot* of code, and allocates a lot of data. Even then, it's nice to save almost 40 MB of memory when reading BldgBlog.
-