Re: A tale of waiting

[Benjamin Otte <otte gnome org>]

On Thu, Jun 25, 2009 at 12:12 PM, Kristian Rietveld<kris gtk org> wrote:
> As a side comment, I am not really sure how fair it is to compare a
> full blown GUI to a command line utility with its output redirected to
> /dev/null.
>
I thought about this quite a bit and decided it was a fair comparison,
as long as I didn't aim to match the numbers exactly. In fact,
launching a binary that has to do a bunch of setup and format the
output of the whole list of files and then comparing it to a file
chooser displaying that directory in an already visible dialog, that
only displays the top 20 results, it seems the file chooser could even
be faster.

> ... I guess the sort function is located in the file chooser dialog
> (as opposed to being inside the model) and thus has to use the
> gtk_tree_model_get() calls.  Since the sort function is called often
> and the main part of the sort function is to fetch the values needed
> for comparison from the model, it is not weird that there is a large
> overhead introduced by GObject's implementation of interfaces.  I
> don't know how many different sort functions are used in the file
> chooser.  If it is only one, you could make GtkFileSystemModel
> implement the GtkTreeSortable interface (I get the feeling you've
> already done that) and move the sort function to be internal to
> GtkFileSystemModel (so it can access all values directly).  Make it
> the default sort function that can be overridden using the
> GtkTreeSortable interface.  This is in fact a circumvention of the
> GtkTreeSortable and GtkTreeModel interfaces, but it does eliminate the
> GtkTreeModel overhead you are seeing.
>
Yeah, I added a quick accessor _gtk_file_system_model_get_value() that
shortcuts gtk_tree_model_get() and got rid of all performance issues.

I just noted this problem as it's a general issue every time you want
to sort with the default tree models and have 10000 or more items. And
I can imagine quite a few places where that would be a relevant
problem. (Including my favorite, the epiphany history and location
bar)

> validate_row() is the main part of the validation functionality.  What
> it basically does is, given a row, it will set the data (retrieved
> from the model) on all cell renderers and then call the get_size()
> method on each renderer.  When done, the tree view knows the minimal
> size this row needs to display itself.  The proper row size is then
> determined and set.  By default, tree view does a full pass through
> the model to do this for each row.  At the end, the sizes of the
> scroll bars will be fully correct.
>
> Fixed height mode bypasses this by only measuring the first row, and
> then set the same size for each row.  Rows cannot have different
> heights in this mode.
>
This would be a worthwhile thing to pursue, as the file chooser rows
have a fixed height, if it weren't for the column widths that also
need to be fixed. And that's not what we want there. Otherwise I'd
have used it already.

A thing I noticed is that the tree view validates cells even if the
cell renderers have a fixed size set. I tried to use that with the
icon renderer (icons all have the same size after all), but it didn't
help.
I looked at the code, but validate_row() calls
gtk_tree_view_column_cell_set_cell_data() followed by
gtk_tree_view_column_cell_get_size(). But to speed this up, you'd have
to merge these two functions into one. And as that's public API, I
wasn't sure how good an idea that'd be.

> A good while ago I have been experimenting with removing the fixed
> height mode and also removing the full pass done through the model by
> default.  Instead, tree view will only validate (i.e. measure) the
> rows that are currently visible.  When you scroll, other rows become
> visible and are subsequently validated.  Based on the heights of all
> rows validated up to a certain point, it will make a guess for the
> entire size of the tree view and update the scrollbars. This guess is
> "good enough" for almost all cases, especially when the row count
> grows bigger.  The guess becomes more accurate as more rows are seen.
> Seemed to work very well and resulted in lightning fast large (4
> million+ rows) variable-height tree views.
>
Yeah, that was an idea I had for speeding up the tree view, too. I'd
be very happy to see such a patch land.
In particular because it would dramaticlly improve scrollbar behavior
when not all files have been validated yet. This currently causes
constant updates and makes the scrollbar jump.

You can see that happening in
http://people.freedesktop.org/~company/stuff/filechooser.gif - it's a
recording of me opening my test directory and you can see me being
irritated at the scrollbar behavior.

> I've more things (mostly refactorings) sitting around that I really
> want to get in a shape to be committed to trunk.  What has been
> holding me off until now is a total lack of time (this will most
> probably change soon, yay) and the lack of an automated test suite for
> tree view.  If somebody has ideas on how to automatically test
> layouting and drawing algorithms for correctness, that would be
> appreciated ;).
>
I'm all for it! :)
About layouting tests, I know that the Mozilla guys use reftests very
successfully, see
http://weblogs.mozillazine.org/roc/archives/2008/12/reftests.html and
Google. What that basically does is taking two widgets by taking a
screenshot of each and checking the images match pixel by pixel. If
written properly, those tests are independant of Gtk theme, settings,
locale, fonts and all that stuff.

Cheers,
Benjamin