GNOME Bugzilla – Bug 312122
disable autosizing of entry view columns
Last modified: 2005-11-29 01:14:51 UTC
gtk+ wastes an inordinate amount of time measuring every string we put into a RBEntryView, whether visible or not. Disabling column autosizing (which doesn't really help much anyway - it just makes the column sizes change a bit while loading the library) makes the rhythmbox UI noticeably faster.
Created attachment 50009 [details] [review] patch The only problem with disabling autosizing is that it means all entry view columns either need to be expanding or have a fixed minimum size. Most of the changes in the patch are there to measure minimum sizes for the non-expanding columns, and I'm not sure this is the best way to do it. The tree view widget somehow calculates a minimum width it'll allow you to resize a column to, but I can't see a way to get at that value.
There is a function (gtk_tree_view_column_cell_get_size) which you can use to get the width of a column - but unfortunately the non-ellipsised text columns (where you have used the templates) don't yet contain any text, so it returns 0. I don't know if there is a better solution than the templates, because of the lack of rows when this code is run. Even if we don't think up a better way of doing it, getting this into cvs would be good - currently it takes about 9 seconds for my playlists to fully load after the library source has, and this patch reduces that to under 2 seconds.
CC myself to remember to test the patch
Created attachment 54088 [details] [review] updated patch Updated to apply to cvs. Looking over it the potentially bad columns are: * Last Played/Date Added/Podcast Date, which might be wider in some locales * Track #, where there may be more than 9999 tracks in a playlist or the string is wider in some locales
One idea I've just had: we dont't have to move away from autosizing completely. We could at least commit a partial version of this to cvs, with the following column properties: * The Playcount and Time columns have their width set by the strings "Never" and "Unknown" respectively (like in the patch) * Track # and the date/time columns stay as autosizing * The title/artist/etc columns have no minimum with and are set to expanding to take up the rest of the space equally (like in the patch) That should provide a reasonable improvement in speed, without the potential l10n problems of using fixed widths for the date/time columns. I'll probably have a go at trying this soon, to see how much improvement there is.
Created attachment 54342 [details] [review] another updated patch updated to cvs head
Created attachment 55076 [details] [review] new patch Now measures dates properly (more or less) and does podcast-specific columns. I've tested date formatting in Japanese (the only translation to use anything besides %Y, %m, %d, %H, and %M) and it works fine.
Looks good. About the only other thing I can think of is that we should probably use g_strdup_printf ("%d", 9999) rather than "9999", to work better in locales that don't use Arabic numerals.
Patch committed to cvs. If there are any remaining problems with this, they will probably be found by people using it and complaining.