Re: GtkNotebook - performance

[Owen Taylor <otaylor redhat com>]

On Mon, 2003-06-09 at 10:18, Petr Pytelka wrote:
> Hi,
> we've been developing application for data collection and we needed lot 
> of GtkEntry. The problem is worse in Win32 (aprox. half Linux performance).
> I've thought that Gtk use double buffering, but when you switch tab you 
> can see repainting of controls. There two phases (1. count control 
> position - draw white rectangles, 2. repaint whole window).
> I think that "first phase" should not be visible. Is it correct ?

Some analysis of your test case; note that this analysis is X
centric, and if it's much slower on Windows than X, then there
is probably something entirely different wrong on windows.
(On a 1.1ghz P3, I just see a flicker with the test case, not
a slow window-by-window redraw)

* It's not typical of most GTK+-2.0 programs since it has lots and lots
of separate X windows. (Each entry has two X windows) That's bad and
good news - it's bad news because  GTK+ isn't optimized for that. It's
good news because we haven't tried to optimize GTK+ much for that so
there is still some easy stuff that can be done.

* Your test case is a post-child for a couple of drawing improvements
I've discussed with Soeren Sandmann

1) Doing predictive exposes when subwindows are mapped or unmapped - 
a predictive expose is when GTK+ knows an expose will occur and 
can start drawing early.
2) Temporarily unset the background of a window when mapping it,
temporarily unset the background of parent when unmapping it.

These improvements should virtually eliminate flicker when switching
notebook pages with subwindows.

(See: http://bugzilla.gnome.org/show_bug.cgi?id=113040
http://bugzilla.gnome.org/show_bug.cgi?id=113310)

* One thing that would reduce overhead in this test case considerably
and possibly could be done in a compatible fashion would be to
combine the two windows of GtkEntry into one window. (There is
significant per-window overhead for handling redraws, and you
get much more X traffic with the two windows, partly because the
outer windows expose region when mapped consists of 4 pieces)

* Caching graphics contexts to reduce the per-window redraw overhead
could help. (Currently two GC's are created and destroyed for every
window redrawn)

Regards,
                                        Owen

> Thanks. Petr Pytelka
>
> My test application:
>   #include <stdio.h>
>   #include <stdlib.h>
>
>   #include <gtk/gtk.h>
>   #include <gdk/gdkwindow.h>
>
>   int createWindow()
>   {
>       GtkWidget *nb;
>       GtkWidget *wnd=gtk_window_new(GTK_WINDOW_TOPLEVEL);
>       int i,f;
>       // create notebook
>       nb=gtk_notebook_new();
>       gtk_container_add(GTK_CONTAINER(wnd),nb);
>       // add pages
>       for(i=0;i<10;i++)
>       {       
>       GtkWidget *table=gtk_table_new(10,10,FALSE);
>       for(f=0;f<100;f++) {
>               GtkWidget *hbox=gtk_hbox_new(FALSE,0);
>               GtkWidget *vbox=gtk_vbox_new(FALSE,0);
>               char buff[20];
>               sprintf(buff,"%i.%i",i,f);              
>               GtkWidget *widget=gtk_entry_new();
>               gtk_entry_set_width_chars(GTK_ENTRY(widget),f%7+3);
>               gtk_entry_set_text(GTK_ENTRY(widget), buff);
>               gtk_box_pack_start(GTK_BOX(vbox),widget,FALSE,FALSE,0);
>               gtk_box_pack_start(GTK_BOX(hbox),vbox,FALSE,FALSE,0);
>        
> gtk_table_attach(GTK_TABLE(table),hbox,f%10,f%10+1,f/10,f/10+1,GTK_SHRINK,GTK_SHRINK,0,0);
>       }
>       gtk_notebook_append_page(GTK_NOTEBOOK(nb), table ,NULL);
>       }
>
>       gtk_widget_show_all(wnd);
>       return 0;
>   }
>
>   int main(int argc, char *argv[])
>   {
>       gtk_init(&argc,&argv);
>       createWindow();
>       gtk_main();
>       return 0;
>   }
>
>
> Owen Taylor wrote:
> > On Mon, 2003-06-09 at 03:43, Petr Pytelka wrote:
> >
> > > Hi,
> > >
> > > I've wrote simple testing application 10pages x 100 GtkEntry on each 
> > > page. When I switched from one page to another it is very slow (I can 
> > > see redrawing of controls) - takes ca. 400 ms.
> > >
> > > I was debugging the problem and it looks like that the GtkNotebook isn't 
> > > written the most optimal. Have you anyone investigating the problem ? Do 
> > > you think that it is possible to improve the performance ? Any ideas or 
> > > tips ?
> >
> >
> > Can you attach your test case? Offhand, I would not expect slowness
> > to be related to the implementation of GtkNotebook.
> >
> > 1000 widgets is a lot ... things aren't going to be especially fast
> > with that many widgets in any case.
> >
> > Regards,
> >                                             Owen
>
> _______________________________________________
> gtk-app-devel-list mailing list
> gtk-app-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list