Re: Avoiding flickering

[Owen Taylor <otaylor redhat com>]

Antonio Campos <acampos@ceronet.com> writes:

[ long quote snipped ]

> I agree with you.
> However, I don't know what this gravity bit is. Could anyone explain it to me so I
> know I am not saying fool things?

Bit gravity is basically a per-window setting saying what to do with the 
contents of a window when it is resized, see a book on Xlib or the Xlib
manual from the X distribution for details.

> Anyway, I agree with you in that many of the flickering of Gtk is due to a complete
> redraw of the background of a window for then repainting the widgets over the
> cleared window. This is annoying,  specially when resizing a window ( in opaque mode
> obviously).

Well, yes, and its been addressed in the code I've been working on, both by changing 
the gravity, and by providing the ability to backing store.

> Although I don't think this will actually resolve all of the flickering problems, it
> could reduce a lot of them, so many applications could run quite smoothly without
> needing double-buffered support (or even drawing the widgets over a pixmap).
> Something has to be buggy in the way GTK draws widgets, because I think QT doesn't
> use strange things like double-buffer (except perhaps back-storing widgets in a
> pixmap for things like the panel on the desktop)

Almost every widget set (including GTK+-1.2) uses double-buffering in at least some
places, so it is in no way a "strange concept". I believe (though I haven't looked at 
the code), that Qt double-buffers drawing in most or all of its widgets, though
it has to be done manually in each widget.

>  and it runs quite smoothly
> (sometimes even better that Windows, that theoretically has more polished
> video-drivers that X has). Have you tried to scroll continuously a text in Kedit? It
> actually runs very smoothly. Is it possible that widgets in GTK are redrawing
> themselves more times than needed?

Not in general no. There are some reasons why GtkText is not quite as fast
as scrolling as it could be in theory (though I can't actually detect any
difference in smoothness of scrolling it between it and kedit) but they have
nothing to do with multiple redraws.

> If double-buffer is going to increase a lot the use of memory, then by all means
> GTK should try to speed things up without using it.

Double buffering has only a minimal effect on memory usage, because the backing
pixmaps are only temporarily allocated on the server during drawing. It does
slow down drawing a bit, because the graphics need to be copied around more.

>  Another idea to avoid flickering (kick my bottom hardly if I'm completely wrong):
> See attached example, and when running it, try opaque maximizing it.
> The example simply consist of a table with 30x30 buttons attached inside it.
> When the window has totally maximized and as widget redrawing if so slow, the table
> still try to redraw itself a few times.
>
> What is happening in the resize? I don't know if I'm right, so please correct me:
> The window receives the resize request, so it clears itself with the default bg
> color and them communicate the table (its child) of the resize. Them the table
> communicate the resize its children (the buttons). Then the children based on the
> size requested by its parent (the table), get its correct size, and communicate it
> to its parent the table. Then the table initiates the redrawing of the children with
> the correct size.
> But, what happens when the table receives another resize request while it is still
> redrawing its children (as asking them for the resize). I suspect from the execution
> of the attached example, that until the table gets completely redrawn, it cannot
> process the next resize event.

All the effects that I seen in your example with GTK+-1.2 are
due to two things:

 - Every time the window changes size, the entire window is redrawn. (minor flicker)
 - Every time the size of a row or column changes size, X clears the row
   or column because of the bit gravity which is set on the buttons 
   (major flicker)

> As Ivan noted, not clearing the window with the bg color could greatly reduce the
> sensation of flickering. But would it help too if the table (a container in the end)
> could stop a resize request in course if it receives another one?.

Resize requests are queued and combined. But once GTK+ starts drawing the
window at a particular size, that can't be interrupted. Within the framework
of 1.4, it wouldn't be hard to change this, but on the other hand, with
my development code your example looks OK anyways, so I'm not sure it is
needed.

Regards,
                                        Owen