Re: oustanding gtkwindow.c FIXME

[Owen Taylor <otaylor redhat com>]

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.

I'd still like to investigate getting rid of this.i 

Regards,
                                        Owen