Re: [gtk-list] Gtk 2.0 (was Re: Tracking object deletion)

[Owen Taylor <owt1 cornell edu>]

Raph Levien <raph@acm.org> writes:

> I think we're going to have to start thinking seriously about the 2.0 
> versions of both Gimp and Gtk. My personal obsession within Gtk is to 
> make handling of huge scrolling windows work well - currently a 
> significant weakness of Gtk.

And of X. But huge windows can't be thought of without paying
attention to the performance of such, and to the intended end uses.
 
> Presently, I deal with this weakness by defining my own parallel widget 
> set, Gzw (Gzilla widgets). It's not too bad, because I only need a small 
> number of widgets. The only substantial ones are gzw_page for displaying 
> the Web page, gzw_table for HTML tables, and eventually gzw_image for 
> displaying images. In each case, there is some overlap with an existing 
> Gtk widget, but also a lot of new functionality that the Gtk widget 
> doesn't provide.

And GTK widgets have a lot of functionality (signals, DND, selections,
focusing, grabs ...) that Gzw widgets don't (can't reasonably) provide.

>  For things like buttons, entries, and other form elements, I just
> embed a Gtk widget.
> 
> This seems like a good provisional approach, but it makes me uncomfortable
> in the long term. Already, we're starting to see a number of applications
> that need large scrolling implemented as monolithic widgets, including
> gtk_text, Jay Painter's CList, and of course Gzilla.  More applications
> are sure to arise, including a spreadsheet. In addition, I'd say speeding
> up the list display in the file selector should also be a major
> performance priority. I see a lot of duplicated work, limits to
> functionality (for example, the CList can handle embedded pixmaps but not
> embedded Gtk widgets), and in general a lack of modularity. 

I think the list is pretty finite:

  The text widget (already handles long text fine)
  HTML handling (Gzw)
  "Grid widgets" (Not currently unified)
    CList
    Tree (HList)
    Spreadsheat

Now it would be nice to unify all of these somehow, and probably
essential for the grid widgets, but I still think that proper Grid
widgets can be handled fairly well in the context of GTK. (See my post
some months back on the issue). The thing is, big widgets are in some
ways fundementally not just collections of small widgets - they need
to scroll and size allocate differently.

> Long term, I think the best solution is to make changes to Gtk that will
> enable large-scrolling for all Gtk widgets. This clearly seems like the
> easiest approach for new programmers to understand. However, it's
> certainly not possible to integrate large-scrolling without breaking
> backwards compatibility with existing Gtk code. I think it is possible to
> do it in a way that requires fairly minimal rework, but it's still a
> hassle. 

Hmmm, I'm somewhat skeptical that a single heirarchy is useful. 
For many large-window applications there are simply too many child
"widgets" for them all to exist in memory at once. (You once said
that Gzw widgets have a minimum 40 bytes/widget overhead. Gzw widgets
with all the functionality of GTK widgets are going to have a great
deal more. 

For situations where you will have 1,000,000 child "widgets" you
need to be able to create and destroy them as displayed. (Which
means you can't use conventional size negotiation) 

When you have 10,000 child "widgets", it would be nice to make them
very light weight. This could mean something like the Gzw widgets,
or it could (for a grid or tree widget) mean something even lighter
like:

struct _Cell {
  CellType type;
  CellAlign align;
  union {
    GdkPixmap pixmap;
    gchar *string;
    GtkWidget *widget;
  } contents;
}

I'm not quite what you mean by "enable large scrolling for all
widgets". Making all widgets be able to be bigger than 32,768 pixels
sounds very difficult and not very useful. (Changing internal
coordinates to be 32 bit wouldn't be to bad, but if you have enough
GTK widgets to span 32,768 pixels, your perforance will be dismal in
any case.)  Rewriting size allocation to work like Gzw (Word wrapping,
separate horizontal and vertical allocation) might be feasible,

> It seems to me that the Linux community deals with about one major 
> compatibilty-impared upgrade a year, with ELF and glibc being the most 
> recent. I don't exactly like it, but this might be the best path for Gtk 
> as well.

It depends on how major the backward-incompatible changes are.
Remember, there are 330,000 lines of code in the GIMP now. A 
change that required rewriting 1% of those might be acceptable.
10-20% would be pretty hard to swallow. ELF and glibc were generally
more in the 1% or 0.1% range. (Depending on on how badly the
program was written to begin with)

To sum up - yes it is a problem but I'm not convinced yet that the
best way to solve it is to make major changes to the existing
GTK widgets.

First priority - figure out what needs to be in GTK 1.0 and do it.

Regards,
                                        Owen