Re: GNOME CVS: gtk+ timj
- From: Tim Janik <timj gtk org>
- To: Owen Taylor <otaylor redhat com>
- cc: Gtk+ Developers <gtk-devel-list redhat com>
- Subject: Re: GNOME CVS: gtk+ timj
- Date: Tue, 12 Jan 1999 21:56:58 +0100 (CET)
On 12 Jan 1999, Owen Taylor wrote:
>
> 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
can you please be more specific? all of the above cases require redraws
on either the widgets or the parents, if areas get queued multiple times
the'll later get coalesced.
> > (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.
that guarrantee is taken care off by gtk_widget_queue_resize doing a
queue_clear on the widget.
> [...]
>
> > 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?
with draw_indicator=TRUE widget->window points to the toggle buttons
parent window since a toggle button is a NO_WINDOW widget in that a case.
the resizing and redrawing code didn't take care about that and would
do all sorts of sick stuff with the partents window like
gdk_window_move (widget->window, widget->allocation.x, widget->allocation.y);
which gives interesting results for e.g. testgtk's toggle button test, where
there's just window -> vbox -> toggle button.
>
> Owen
>
---
ciaoTJ
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]