Re: GNOME CVS: gtk+ timj

[Owen Taylor <otaylor redhat com>]

Gnome CVS User <gnomecvs@redhat.com> writes:

[....]

> Log message:
> Tue Jan 12 13:47:07 1999  Tim Janik  <timj@gtk.org>
> 
> * reworked the redrawing heuristics somewhat, this fixed a bunch of
> existing redrawing problems and majorly reduces overall redrawing needs
> during normal operation. basically we now only queue redraws when
> neccessary and much rely on the draw_area coalescing code in gtkwidget.c
> to optimize the queued portions. widgets will now upon reallocation only
> get redrawed if their allocation has changed. upon hide/show only the
> area allocated by the child will be queued for the parent, this has the
> side effect that parents which change their appearance in dependance on
> the numer of visible children have to keep track of their children's
> visiblity and eventually fully redraw themselves. this is a minor
> constrain with great benefits in terms of redraw reduction, and only got
> triggered by the notebook widget.
> 
> * gtk/gtkwidget.c:
> (gtk_widget_queue_clear): don't bother if width and height == 0.
> (gtk_widget_queue_clear_child): new static function to queue a redraw of
> the area obscured by a child on a parent.

> (gtk_widget_queue_resize): queue_clear the widget if it is drawable.
> (gtk_widget_show): queue resize on the widget before showing.
> (gtk_widget_hide): queue resize on the widget after hiding.
> (gtk_widget_map): queue_draw the widget after mapping.
> (gtk_widget_unmap): queue_clear_child the widget.
> (gtk_widget_size_allocate): queue_clear_child and queue_draw if the
> widget's allocation changed.
> (gtk_widget_unparent): queue_clear_child so the parent redraws obscured
> portions.

Big problem here, you're missing a whole lot of
tests for NO_WINDOW widgets. So GTK will be doing a 
whole lot of extra work

> (gtk_widget_real_show):
> (gtk_widget_real_hide):
> (gtk_widget_real_map):
> (gtk_widget_real_unmap):
> (gtk_widget_real_size_allocate): don't bother with redraw queueing,
> descendants that override these functions don't do either and we handle
> all redrawing/resizing related stuff before or after the signal emission
> now.
> 
> * gtk/gtkcontainer.c:
> (gtk_container_resize_children): don't bother about redrawing anymore
> since gtk_widget_size_allocate handles that for us now.

Another big problem - haven't tested this yet, but it looks
like no redraw is going to be queued if the size didn't change.

Right now the guarantee is that if a widget queues a resize,
it will eventually get a redraw. I'm sure we are going
to trigger bugs somewhere by removing that guarantee.
 
[...]

> Mon Jan 11 20:44:35 1999  Tim Janik  <timj@gtk.org>
> 
> * gtk/gtkstyle.c: changed gtk_style_apply_default_pixmap to
> gtk_style_apply_default_background which takes an extra argument
> copy_area to determine NO_WINDOW widget pixmap copying.
> changed callers accordingly.
> 
> * gtk/gtktogglebutton.c:
> (gtk_toggle_size_allocate):
> (gtk_toggle_button_expose):
> (gtk_toggle_button_paint): avoid messing with our parent's window if
> toggle_button->draw_indicator == TRUE and we are a NO_WINDOW widget.

Could you explain what these changes fix? 

                                        Owen