Re: Wish before 1.0 - clist

[Owen Taylor <owt1 cornell edu>]

Patrice Fortier <Patrice.Fortier@aquarel.fr> writes:

> As 1.0 will be released soon now (well, sooner than I expected), i'd
> like to make a couple of comments on the clist widget.
> 
> According to me the clist widget is bloated.
> In clist you have a column list widget + a wiewport widget + a
> scrolledwindow widget.
> What do we gain with this?
>  - scroll is maybe slightly faster (read more before reply now :))
>  - when resizing the column widget (add / remove entry) we *may*
>    avoid an expose event.
> 
> For the standard user, who will test list+scrolledwindow instead 
> of the clist, the difference with scroll speed is quite amazing.
> Why?
> Because the clist expose event is well designed (at least compared
> to the list widget).
> As the list entries in the clist are "gadgets" (their drawing is
> handled by the clist, not the entry itself), and are all of the
> same size (at least height), you can know exactly which entries
> need to be redrawn when an expose event occur.

> This is not the case of the list widget (in which entries are widget),
> which send the expose event to *all* its children (even if the child
> is NOT visible).

I don't think so:

      children = list->children;
      while (children)
	{
	  child = children->data;
	  children = children->next;

	  if (GTK_WIDGET_NO_WINDOW (child) &&
	      gtk_widget_intersect (child, &event->area, &child_event.area))
	    gtk_widget_event (child, (GdkEvent*) &child_event);
	}

from GtkList.c. In fact, GtkListItem widgets are not NO_WINDOW, so
this code is completely inoperative - X handles all the expose events
it won't send expose events to windows which aren't on the screen.

The real problems are simply that:

* creating Widgets is memory consuming and slow when you are talking
  about creating 80,000 widgets. (Or even 8,000)

* Creating X windows is "slow", 1.5ms per window, and you have a 
  window for each ListItem.

* X windows are limited to 32768 windows long, so this is as big
  as a scrolled window can get. (Unless you play tricks by moving
  things around, which is going to be quite expensive when you
  have 1000's of embedded widgets)

> This is the reason why the clist is much more efficient than the list+
> acrolledwindow.
>
> I wanted to modify the clist widget to test this theory, but infortunatly
> I have too much work now to do it (can't code on gtk before 2 weeks :().
 
> What should be done before 1.0?
> clist should not have its own scrollbars and viewport. the acrolledwindow
> already do that. The speed gain is due to the expose event of clist,
> not the bypassing of scrolledwindow.

> Why should it be done?
> the scrollbars handling + viewport bloat the clist code.
> scrolled window is useless if people bypass it to include it in
> their own widget.
> This is a bad example for gtk 1.0 users.
> This makes the clist widget design inconsistent with the other widgets
> of gtk.

If you want consistency, you have GtkList. Unfortunately, the price
of consistency is size limitations and slow performance.
 
> I can here some of you answer "We can't delay 1.0 more".
> I really can't say you're wrong.
> But think about this:
> 
> When 1.0 will be out, a lot of new users will look at it and use it (cool).
> They'll use the clist widget (never the list widget) (cool).
> So, first, if you wan't to change the behaviour of clist in 1.1, you'll
> have to change all the programs using clist (a lot of them).
> Now, let say I'm a new user.
> I need a list widget doing something a bit different than clist so I need
> to write my own widget... How can I do it?
>  - look at clist widget (efficient) and write my widget using its code.
>  - or look at scrolled-window, and list widget which are inefficient
>    (nobody use it, and as a user I won't look in the sources to find
>    the reason *why* it is so inefficient).

The CList widget could certainly be more general. I think of it
as a special case of an imaginary "Grid widget". But we have several
options (other than delaying the release of 1.0 for another 3 months
;-) to provide upgrade paths to people using the form found in 1.0:

 - We can reimplement the CList interface using whatever more general
   widget it is replaced with.

 - We can leave the CList there and encourage people to migrate
   their code.

(It should be mentioned that after 1.0, by incorporating ideas from
Gzilla, we may be able to make the List considerably more adaptable
to large lists; but I doubt that approach will ever be able to handle
cases where there are 100,000 child widgets)

The release of GTK is not being made because it is now perfect and
will never be changed, but because the GIMP is ready to be
released. (And because people want to make major changes
(themeability) to GTK, so we need to get something out while things
still work)

I hope this explains the situation a bit more,

                                        Owen