[gtkmm] RE: Custom TreeModel (was RE: signals versus vfuncs)

[Murray Cumming Comneon com]

> >>Do you still feel that a custom tree model is unnecessary? 
> My feeling 
> >>is
> >>that for _massive_ amounts of lines the C++ wrapper imposes 
> too much 
> >>overhead (vfunc indirection, iterator conversion etc. sum 
> up once the [] 
> >>operator on a Gtk::Tree::Row is used many times to access 
> the columns).
> >>
> >>My std::map based model easily handles sorted 
> insertion/reorganization
> >>of 100k rows into a tree without significant slowdown.
> > 
> > 
> > I would like to see some proof that it's faster in GTK+ when using 
> > normal TreeStores or ListStores. Such proof should be in 
> bugzilla as a 
> > gtkmm performance bug.
> 
> I really have no intention to port a three additional library 
> involving, 
> heavily STL using _example_ program to C (custom smart 
> pointers, custom 
> GValue like with user defined sort order etc.).

I don't think a simple test case should be too difficult. But even if you
don't put a test case in bugzilla, please report your suspicion to bugzilla
and maybe someone else will test the theory with test cases.

> And to be honest, I really gave up to further research this 
> issue once 
> you told me so, back then. The implementation was using STL's 
> lower_bound on Gtk::TreeStore and performed poorly, now with minimal 
> changes and std::map it flies.
> 
> Perhaps I might code an trivial example in C++ with 
> Gtk::TreeModel vs. 
> GtkTreeModel. If you _really_ want to analyze this.

I do. gtkmm should not require you to write a custom tree model to get
better performance, unless GTK+ also requires it. And I won't try to solve
such a problem until I know that such a problem exists.

> And if I 
> ever find 
> the time for it. Feel free to ask/confirm.
> 
> >>PS: It seems that because of the
> >>Gtk::TreeModel::add_interface(get_type()); call during type 
> creation I 
> >>cannot use the Glib provided custom type infrastructure.
> > 
> > 
> > I'm not sure what you want to do instead, or can't do. What "Glib 
> > provided custom type infrastructure" do you mean? API docs URLS are 
> > nicest.
> 
> I did not find any API docs when I researched implementing 
> Gtk::Interfaces.
> 
> While I really like the easy Glib::ObjectBase(typeid(...)) way of 
> getting a GType (e.g. custom cellrenderer), I have to use 
> Glib::ObjectBase("MyTreeModel"), 
> Glib::Object(Glib::ConstructParams(myclass.init(), (char*) 
> 0)), create a 
> custom Class struct:
> 
> class MyTreeModel_Class : public Glib::Class
> {public:
>          const Glib::Class& init();
>          static void class_init_function(void* g_class, void* 
> class_data); };
> 
> a custom GTypeInfo
> and call g_type_register_static and 
> Gtk::TreeModel::add_interface. IMHO 
> it should be possible to just derive from some class (e.g. 
> Gtk::CustomTreeModelBase) and override the vfuncs.

OK, that's horrible. You should never have to create the GCLass yourself, or
write those C callbacks. And I don't think we do that in our custom
cellrenderer example. Please add your example code here:
http://bugzilla.gnome.org/show_bug.cgi?id=124297
and I will try to get around to it later.
 
> Perhaps the key to this overhead is the fact that a TreeModel 
> is not a 
> GObject and there's no way to specify additional things to be done at 
> GType registration "TreeModel::add_interface" (is there?).

Yes, that might be relevant - Gtk::CellRenderer is a Gtk::Object already,
but Gtk::TreeModel is just a Glib::Interface.

> > The problem, I think, is that the Gtype must come from the derived 
> > type, but you want that type to be registered in the base 
> C++ class, 
> > whose constructor runs before the derived part of the class 
> exists. I 
> > don't think the
> > add_interface() call is too bad for something that is very 
> rarely done.
> 
> add_interface is ok with me. It's the bulk of lines needed to get a 
> minimal custom TreeModel that bothers me.

Yes, that's surprising and horrible. I'll try to investigate before our 2.4
API freeze.

However, as I said above, I don't think this should be necessary for
performance.

Murray Cumming
www.murrayc.com
murrayc usa net