Re: forcing immediate redraw on widget

[M Santhoff t-online de (Marc Santhoff)]

Am Di, den 27.04.2004 schrieb Gus Koppel um 18:32:
> Marc Santhoff wrote:
>
> > Hm, can it be the window manager (windowmaker)? I had big round eyes
> > ten minutes ago when i (for the first time ever) minimized the window
> > and restored it. After that the whole bar was green as should be, not
> > only at the places the slider had stepped!
>
> I strongly doubt that. On restauration of a window the WM basically does
> nothing else than invalidating the entire area of the window, that is
> all widgets in it, so that they can be redrawn next time the main loop
> enters.
>
> Btw, minimizing + restoring a window FOR THE FIRST TIME EVER after
> having programmed quite a lot in GTK+???

:)) Yes, definitely. The program runs on a TFT with 640x480 pixels and
is so small on my desktop that I hardly notice ...

> Try to drag other windows in front of your application, so that they
> cover and then uncover your GtkHScale. You will see the same correct
> behaviour then.

Yes, all green as it should be.

> > Graphics driver is Xfree4.3s MGA driver on Matrox MGA400 (development
> > machine, ASAP i will run it on the target machine for some
> > investigations on this issue).
>
> I know about a machine which produces lots of drawing errors when it
> comes to Java + Swing on Windows (with all Java applications). That's
> why that possibility can't be ruled out completely for other systems as
> well, though it was least probable.
>
> > It is 0, every time it's called.
> > [...]
> > And here it is 1, as expected.
>
> Yes, those are the expected results. So I guess a GDK event to force a
> redraw of the GtkHScale has been created just as expected. For some
> reason the event just isn't handled by the GtkHScale inside the main
> loop as expected. There could be a bug in gtk_widget_queue_draw () which
> leads to wrong or invalid area information of the widget to be redrawn.

Ah, I've been looking at the sources but did not understand that much.
Maybe this helps ...

> Another approach which just came into my mind is not to focus on the
> GtkHScale only. Try to invalidate one of the PARENT CONTAINERS of your
> GtkHScale instead. Eventually, when you invalidate the entire GtkWindow
> you're doing mostly the same as the WM does when a minizmized window
> gets restored. Invalidating the entire window will not be what you want,
> though. But I suppose there are some levels of containers in between?

Good point, I'll try that next.

Marc