Re: Setting and unsetting GTK_FULLDRAW_PENDING

[Havoc Pennington <hp redhat com>]

nicholas allen <nicholas allen ireland sun com> writes:
> I have noticed a strange behaviour that happens sometimes when
> running an inhouse AWT test for Java using the Gtk toolkit peers
> that we have.
>
> Basically, the test adds and removes lots of Java components from a
> window. This in turn adds and removes gtk widgets to/from the
> window. After a short while of running the window stops repainting
> itself (at the gtk level and the java level too). What appears to be
> happening is that expose events are being ignored. This seems to be
> an optimization in gtk_widget_event where it checks the
> GTK_FULLDRAW_PENDING flag to determine if the widget or a parent has
> a full redraw pending. If this is the case then it ignores the
> expose event and does not fire the expose signal on the widget. This
> means that the widget does not draw itself.
>
> The flag is unset in gtk_widget_redraw_queue_remove function and is
> set in the gtk_widget_queue_draw_data function. What must be
> happening is that the flag is being set but is never being unset.
>
> Does anyone know what could cause the gtk_widget_queue_draw_data
> function to be called for a widget (which would set the flag) but
> not the gtk_widget_redraw_queue_remove (to unset the flag)?

It wouldn't be too surprising if this was a GTK bug of some kind -
your test doesn't sound like something anyone would have tried
before. ;-)

Maybe you can debug it, or try to come up with a test case we could
compile/run?

As a 5-minute theory, it looks a bit like gtk_widget_unparent() only
removes the widget from the redraw queue if
GTK_WIDGET_REDRAW_PENDING() - maybe at some point GTK_FULLDRAW_PENDING
is set but not GTK_REDRAW_PENDING? I can't find that mistake in the
code quickly, but maybe it happens.

Perhaps a bug in your container? Do you call gtk_widget_unparent()
when widgets are removed?

Havoc