On Fri, 2004-10-29 at 11:11 +0800, Not Zed wrote: > I just read your "blog" - you're wrong about how ETree works, or > mistaken about what evolution mail uses (some things have changed > since you last looked at it). It only uses an ETreeModel, even for > the flat view. I'm not responding on the "blog" since I don't think > that is very appropriate, or very polite. I don't really want to get > into an argument either, but I guess I have no choice.
Sorry if it sounded like I was trying to raise an argument; I wasn't :) I didn't mean to say that GtkTreeView doesn't have performance problems; it certainly has them, and it blows big fat goats that we can't fix some of them due to API/ABI compatibility requirements. > ETreeSelectionModel subclasses ESelectionModel directly, it doesn't go > anywhere near ESelectionModelArray. When you ask for the selected > rows, you get the result of a g_hash_table_foreach. So first point, > GtkTreeView's selection retrieval interface is O(N) on the number of > rows, and ETree's is O(N) on the number of rows selected. Obviously > in almost any real application you're looking up the selected row(s) > constantly, so its something which should be fast in the common case > (i.e. 1 row selected). You are right, of course. I was looking at ETableSelectionModel, not ETreeSelectionModel. I quite like the idea of using a hash table for tree selections... maybe GtkTreeSelection could be made better with one. All the red/black tree stuff is private, anyway, so we could make it no longer keep the selection data there. > Second, and this is also a factor that helps the selection model work > at all, ETree doesn't use this GtkTreePath indirect > reference-to-a-pointer crap (and it is crap). The ETreePath's are > pointers to the actual tree nodes used in the tree. And dereferencing > an ETreePath is O(1) (where 1 is close to 0), whereas it's O(N) for a > GtkTreePath - depending on the tree implementation, and for most > practical tree implementations it is O(N). This means you don't need > this GtkTreeReference stuff, since all Paths are already 'static' > references. Some of the performance issues from using GtkTreePath's > for most uses (not the selection stuff) can be mitigated by vastly > complicating your tree model, but that seems an expensive cost for > something which doesn't add any value to start with anyway. Yeah, I'm not sure that GtkTreePath and GtkTreeRowReference are a good idea for the abstract models. They may be useful for GtkTreeStore if you want to make it totally anal-retentive model/view. But in the abstract model, I agree that opaque paths are better. GtkTreeView uses row references for the cursor row, for example, so that if you insert/delete rows above it then it will still be easy to find. But I guess the tree could just as well keep track of that by itself. We should definitely talk about designing a Better(tm) tree/list widget. Mono needs one :) Federico _______________________________________________ evolution-hackers maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution-hackers
