Re: oustanding gtkwindow.c FIXME

[Tim Janik <timj gtk org>]

On 15 Aug 2001, Owen Taylor wrote:

> Tim Janik <timj gtk org> writes:
> 
> > static void
> > gtk_window_move_resize (GtkWindow *window)
> > {
> >   [...]
> >       /* Increment the number of have-not-yet-received-notify requests */
> >       window->configure_request_count += 1;
> > 
> >       /* We have now sent a request since the last position constraint
> >        * change
> >        */
> >       info->position_constraints_changed = FALSE;
> > 
> >       /* we are now awaiting the new configure notify event in response to our
> >        * resizing request. the configure event will cause a new resize
> >        * with ->configure_notify_received=TRUE.
> >        * until then, we want to
> >        * - discard expose events
> >        * - coalesce resizes for our children
> >        * - defer any window resizes until the configure event arrived
> >        * to achieve this, we queue a resize for the window, but remove its
> >        * resizing handler, so resizing will not be handled from the next
> >        * idle handler but when the configure event arrives.
> >        *
> >        * FIXME: we should also dequeue the pending redraws here, since
> >        * we handle those ourselves in ->configure_notify_received==TRUE.
> >        *
> >        * FIXME: not sure the above FIXME is correct, because we only
> >        * queue draw in size allocate if the size actually changes,
> >        * so if the update area for the window contains stuff
> >        * unrelated to sizing (should be rare actually) then we
> >        * might lose that info.
> >        */
> >       gtk_widget_queue_resize (widget);
> >       if (container->resize_mode == GTK_RESIZE_QUEUE)
> >         _gtk_container_dequeue_resize_handler (container);
> > 
> > havoc, the first FIXME is still correct, and we're not loosing
> > redraw portions, because when we receive the new configure_event
> > with configure_notify_received=TRUE, we unconditionally queue
> > a resize in gtk_window_configure_event() and therefore also expose
> > the whole window. the code here just knows that, because we just
> > resized or moved the window, we'll definitely receive a configure
> > event and therefore reallocate and redraw the whole GtkWindow at
> > some point, so until then, we shouldn't do either.
> 
> But the unconditional queue-redraw-on-the-whole-window we do
> when we receive a configure event is causing us to redraw
> quite a bit more than necessary -- with speed penalties when
> we double-buffer and flash penalties when we don't.

we only got here, because a resize was queued on the window, and
therefore _all_ its contents need to be redrawn (since we guarantee
that, if you do queue_resize (foo), foo will get size requested,
size allocated and get fully redrawn).
however, in the case where we also had to move/resize the window, we know
that we'll get a wm response via configure event, and that might again
change our size. so if we did reallocate/redraw right here, we might be
doing extraneous work.
that's why we discard the resize/redraw here, and set a flag (the flag
being configure_request_count>0) to indicate that the resize/redraw should
be handled when we receive the configure event.

the only problem remaining is that we dequeue the resize handler here, but
can't really dequeue the redraw yet, since afaik, we can't yet discard
all invalidated areas of a gdkwindow tree.
so what needs optimizing is the extra redraw we're doing right after this,
eventhough we didn't actually do the resize yet.

> 
> Regards,
>                                         Owen
> 

---
ciaoTJ