We chose the new backgrounds for 2.24 at GUADEC, but it wasn’t until a few weeks ago we got round to integrating them into the gnome-backgrounds module. Have a look on the theming blog for a preview of the new images.
(Yes! I get first post to the new GNOME theming blog!)
Back from Guadec, which was great. Few interesting points:
My new tasks are to release some version of Monet fairly soon, and to start work on a GTK+ theme engine to implement some of the css style GTK+ theming thoughts I had a while back.
Thanks to everyone that helped organise this years Guadec. It was a great event and of course great to catch up with old friends and meet new ones.
A while back I wrote a little script in Python to test some of the new features of the Openmoko Freerunner. Several people have requested the source code, so I’ve cleaned it up a bit and made it available here: http://folks.o-hand.com/thomas/openmoko/gta02.py
There are a couple of items on the todo list and I’m sure anyone with more decent Python skills than me could do a fair amount of cleaning up with it. However, it works and is useful at least as a demonstration.
It requires python and pygtk.
I really like the Baobab disk usage analyser that is included in gnome-utils, but more often than not I’m in the middle of using Nautilus to sort through my files and folders when I want to analyse the disk usage. So I thought, wouldn’t it be convenient if I could just get to Baobab straight from a context menu in Nautilus? It turns out writing Nautilus extensions was much easier than I thought, especially when you start by copying an existing one. Within a few minutes, I had my Analyse Disk Usage context menu item. I’ve posted it in bugzilla as a patch to gnome-utils, in case anyone else thinks it would be useful. If it was integrated into GNOME, it should probably be disabled by default and an option in Baobab would enable it.
And in case I haven’t explained it very well, he’s a screenshot:
Plenty of bugs fixed in this version. I am hoping to use this as the release candidate for version 1.0, so please send in any updated translations either to me (thomas at openedhand.com) or attach them straight to bugzilla. Also, I haven’t fixed many Maemo issues because we don’t really support the Maemo version (Maemo already has an address book anyway…). However, I’m more than willing to apply patches if people are able to supply them.
I’d like to add a special thanks to Adrien Bustany and Gilles Dartiguelongue for their patches that I’ve included in this release. If anyone else has any (small) feature of bug fix they would like to see done before 1.0, now is the time to start working on your patches!
Overview of Changes in 0.9 (since 0.8)
Bugs fixed:
Sources
Tarballs: http://pimlico-project.org/sources/contacts/
Subversion: http://svn.o-hand.com/repos/contacts/trunk/
Reporting Bugs
Please report any bugs using the bugzilla bug tracker at:
http://bugzilla.o-hand.com/
Website
Screenshots and more information available at:
http://pimlico-project.org/contacts.html
It seems Federico’s hunch was correct and the majority of time in show_all is spent analysing icon themes and loading the images.
I noticed that /usr/share/icons/gnome/icon-theme.cache was missing, so I ran gtk-update-icon-cache to generate the file and the result was quite significant.
Before:
After:
The total time to execute show_all went from 0.85 to 0.24 seconds, which is a reduction of about 72% and saves over half a second of start up time. I am now left wondering why the icon-theme.cache was not present and whether I have a more responsive desktop as a result of creating the cache. Perhaps we should be running gtk-update-icon-theme-cache as a post-install operation for gnome-icon-theme?
I’m sure I’m not the only person to have noticed that gnome-appearance-properties takes quite a while to start up. On my system (a 2GHz Athlon XP), it takes an incredible three seconds to start this little preferences application.
So, I decided to do something about it. I used the Federico Technique to insert some debug messages to create a graph of the start up process.
My first attempt produced this graph:
From this, it is clear there are a few bottle necks during start up, with desktop_init being the biggest. desktop_init is the function that initialises the desktop backgrounds tab of the capplet. So, to investigate quite why this was taking such a long time to complete, I added some more log points.
From this, it was quite clear that the time was being consumed entirely by creating the file chooser widget, used when users want to add new backgrounds to their list. So I added yet more log messages to determine if there was one or more function calls responsible:
It turns out that the gtk_file_chooser_dialog_new_with_backend() function is taking just over 1.5 seconds to complete, or approximately half the start up time for the entire application. Thankfully, the widget is not required until the user actually clicks the “Add Wallpaper” button, so by delaying the creation of the widget, we can reduce start up time by half.
There are clearly some more places to investigate and I’ve started looking into the app data init and themes_init sections.
The next biggest places to investigate appear to be the gnome_theme_init, thumbnail generation and the style_init. However, the biggest block by far appears to be show_all, which is now taking up almost half the startup time.
Does anyone know have any ideas about why gtk_file_chooser_dialog_new_with_backend() took so long to finish, and indeed why the show_all function take so long to complete? Would it be practical to only call gtk_widget_show when the tab becomes active? I suppose there is only one way to find out…
More videos from Guadec 2007 available.
The new videos are:
![[ ]](http://www.gnome.org/img/24x24/video.png){kind=small}
Anne Østergaard – People are our most important asset – Why Organizational or Corporate Culture in FLOSS Organisations Matters.ogg
Ari Jaaksi – Nokia, maemo, and stuff.ogg
Geodata standards, GeoClue project.ogg
James Vasile – Legal Issues and Free Software.ogg
Jamie McCracken – Tracker and the next generation desktop.ogg
Jim Krehl – The New Main Menu: An Interactive Alternative to Hierarchy.ogg
Joe Shaw – Too Many Metas: A 10,000 ft. view on building a metadata desktop.ogg
Mirco Müller – lowfat, a possible path towards GNOME 3.0_4.0.ogg
Philippe Normand – Elisa: Media-Center for masses.ogg
Thomas Vander Stichele – Practical Project Maintenance.ogg
They’re available on either ftp or http:
Last Friday I decided to use Valgrind to check the memory usage in opkg and discovered that it was leaking quite a substantial amount of memory.
Over the last two and a half days I’ve been fixing all the memory leaks exhibited by running my libopkg_test application. I have reduced the directly lost and indirectly lost memory to 0 bytes. The reachable memory at exit has been reduced to 29kB (down from ~13MB), with the remaining blocks belonging to libgpgme and libcurl which does not appear to be freed by their
respective de-initialisation routines.
Having had such a detailed look at the code, I am fairly certain further optimisation work is possible in terms of both memory usage and speed.
Some interesting statistics:
I used Valgrind’s memcheck tool to help identify the leaks and massif to visualise the memory usage. It seems the Valgrind authors have remove the postscript output from massif in favour of an ascii chart. I’d be interested if anyone knows a way to display the massif output in a more graphical (non-ascii) way.
N.B. The scales on the two graphs are different, so be sure to read the axis when comparing!
Before the cleanup…
ERROR SUMMARY: 2 errors from 1 contexts (suppressed: 67 from 1)
malloc/free: in use at exit: 14,808,479 bytes in 577,152 blocks.
malloc/free: 1,145,825 allocs, 568,673 frees, 1,444,779,097 bytes allocated.
For counts of detected errors, rerun with: -v
searching for pointers to 577,152 not-freed blocks.
checked 12,358,812 bytes.
LEAK SUMMARY:
definitely lost: 611,971 bytes in 40,899 blocks.
indirectly lost: 1,425,560 bytes in 83,798 blocks.
possibly lost: 183 bytes in 7 blocks.
still reachable: 12,770,765 bytes in 452,448 blocks.
suppressed: 0 bytes in 0 blocks.
MB
22.73^ #
| @#
| @ @# : .
| ,@@ @# : : :. : . .. :::
| , @@@ @# : :,: :: : : :: :::
| ,@ @@@ @# : :@: :: : : :: :::
| , @@ @@@ @# : :@: :: : : :: :::
| @@ @@ @@@ @# : :@: :: : : :: :::
| , .@@ @@ @@@ @# : :@: :: : : :: :::
| @@. . :@@ @@ @@@ @# : :@: :: : : :: :::
| .@@@: : :@@ @@ @@@ @# : :@: :: : : :: :::
| . :@@@: : ..@ .:: :@@ @@ @@@ @# : :@: :: : : :: :::
| @: :@@@: ::. . ::@ : : :::: :@@ @@ @@@ @# : :@: :: : : :: :::
| @@: :@@@: ::: : ::@ : : :::: :@@ @@ @@@ @# : :@: :: : : :: :::
| , @@: :@@@: ::: : ::@ : : :::: :@@ @@ @@@ @# : :@: :: : : :: :::
| .@ @@: :@@@: ::: : ::@ : : :::: :@@ @@ @@@ @# : :@: :: : : :: :::
| : :@ @@: :@@@: ::: : ::@ : : :::: :@@ @@ @@@ @# : :@: :: : : :: :::
| .: :@ @@: :@@@: ::: : ::@ : : :::: :@@ @@ @@@ @# : :@: :: : : :: :::
| :: :@ @@: :@@@: ::: : ::@ : : :::: :@@ @@ @@@ @# : :@: :: : : :: :::
| : :: :@ @@: :@@@: ::: : ::@ : : :::: :@@ @@ @@@ @# : :@: :: : : :: :::
0 +----------------------------------------------------------------------->MB
0 73.83
Number of snapshots: 53
Detailed snapshots: [6, 7, 8, 11, 12, 13, 21, 30, 31, 32, 33, 34, 35, 36, 37, 38 (peak), 41]
The two peaks in the graph represent the parsing of the repository data into a hash table. In my test application, the repository data is updated from the feeds, so the package lists are re-parsed. Previously, the main de-initialisation procedure for opkg (which, I hasten to add, was inherited from ipkg) did not free the hash table of packages properly, which meant every time the package list was refreshed, the entire hash table of packages would be leaked. Had a user refreshed the package list several times in one session, it’s likely the device would very quickly have run out of memory.
After the cleanup…
ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 65 from 1)
malloc/free: in use at exit: 29,064 bytes in 2,013 blocks.
malloc/free: 1,145,726 allocs, 1,143,713 frees, 1,443,951,146 bytes allocated.
For counts of detected errors, rerun with: -v
searching for pointers to 2,013 not-freed blocks.
checked 390,804 bytes.
LEAK SUMMARY:
definitely lost: 0 bytes in 0 blocks.
possibly lost: 0 bytes in 0 blocks.
still reachable: 29,064 bytes in 2,013 blocks.
suppressed: 0 bytes in 0 blocks.
Reachable blocks (those to which a pointer was found) are not shown.
To see them, rerun with: --leak-check=full --show-reachable=yes
MB
13.04^ # .
| # :
| :# ::
| .:# @ ::: :
| ::# @ .::: :.
| @::# @ . .. :::: :: .. ,. ,:
| :@::# @: .:@:: : ::::: :@ :::@: .:@:.
| .:@::# @: .::@:::::. .::::: :@. :::@::::::@::
| ,::@::# @: :::@:::::: .:::::: :@: :::@::::::@:::
| @::@::# @: :::@::::::. ::::::: :@: :::@::::::@::.
| ,@::@::# @: :::@::::::: .::::::: :@: :::@::::::@:::
| ,@@::@::# @: :::@:::::::. .:::::::: :@: :::@::::::@::::
| @@@::@::# @: :::@:::::::: ::::::::: :@: :::@::::::@::::.
| .@@@::@::# @: :::@:::::::: ::::::::: :@: :::@::::::@:::::
| :@@@::@::# @: :::@::::::::: . ::::::::: :@: :::@::::::@::::::
| :@@@::@::# @: :::@:::::::::. : ::::::::: :@: :::@::::::@:::::.
| ::@@@::@::# @: :::@:::::::::: : ::::::::: :@: :::@::::::@::::::,
| .::@@@::@::# @: :::@:::::::::: :: ::::::::: :@: :::@::::::@::::::@
| :::@@@::@::# @: :::@::::::::::: .:: ::::::::: :@: :::@::::::@::::::@:
| ,:::@@@::@::# @: :::@:::::::::::. ::: ::::::::: :@: :::@::::::@::::::@.
0 +----------------------------------------------------------------------->MB
0 94.44
Number of snapshots: 76
Detailed snapshots: [1, 5, 6, 7, 10, 13 (peak), 14, 19, 32, 47, 53, 63, 73]Bad Behavior has blocked 9 access attempts in the last 7 days.