Re: Avoiding flickering

[Owen Taylor <otaylor redhat com>]

Ivan Popivanov <popivan@gmx.net> writes:

> Hi,
> 
> It seems to me that you totally missed my point. I'll try to be more
> precise. Imagine a situation (the same as in last letter) that you have
> a parent window and a child window. The child window occupies the whole
> parent area, in other words the parent is not visible at all (toplevel
> widget and for example a clist inside it). Whats the way X server does
> the redraw? First the parent and after that the child. When the parent
> got redrawn it WILL overwrite the child contents. 

If there is a child window, drawing on the parent will _not_ overwrite
the child widget. (OK, will not overwrite the child widget unless
you set some special flags to make it do so.)

> This has nothing to do
> with gravity! On slow systems there will always be flickering! But there
> is only one exception - namely, the parent has no background (pixel or
> pixmap). 

> So, setting no default background, we can achieve no X server
> redrawing. Even if you write a small application using a toplevel window
> with no default background, there WILL be a flickering in current
> release of gtk. Why - simply because of the BAD child redrawing. Now,
> maybe the reason for clearing of the whole child area is window gravity,

The reason why widgets in GTK+-1.2 are cleared long before they are
redrawn is because of window gravity, that's all.

> and maybe it is impossible to the clearing and redrawing in one pass (I
> wouldn't believe this, because in my example with clist, it (the clist)
> draws in the whole its (child window) area, so there is no need to clear
> it explicitly, but that's what the code in clist really does!), but even
> in that case, if you use double buffering, you should only buffer the
> child drawing! 

The double-buffering I've implemented for GTK+-1.3 _only_ buffers during
drawing, so there is no long-term use of memory, the maximum memory
used is the size of your largest window, and if a window never gets
exposed, a backing pixmap for that window will never be ceated.

> That already means sparing a memory of about 1 Mb! If you
> implement only a double buffering, without modifying the parts I've
> already mentioned, everyone will use double buffering for all windows to
> avoid flickering - another drawback in gtk is the number of windows it
> uses,

GTK+ tends to use a lot less windows then most toolkits. Do you have
any particular reason to think that these are a performance problem.

>  but more on this later - so I'll let you calculate the expenses
> speaking in Mbs of RAM.
> Don't tell it is impossible to do because of ... (mainly gravity).
> Windows does this and there is no reason to believe that X server
> imposes restrictions in that sense.

I'm confused here. Windows does double-buffer some widgets, gravity
is _completely_ implemented in the X server, so is in no way
a common concept with Windows...

> You may ask, why I am not providing an example. I'll provide one as soon
> as possible. I actually have coded the example with parent and clist for
> a child, but I am currently changing the code of clist because of the
> horrible redrawing there - refill the entire area as many times as possible.

The CList flickers a lot, yes. That has very little to do with general
drawing in GTK+.
 
> I have mentioned the problem (in my opinion, of course) with the number
> of windows in gtk. For such simple things (as buttons in clist title
> bar, buttons in toolbar, menu items and so on) gtk uses different windows.
> I'd like to remind you, that in Microsoft Word 2 all of the buttons in
> toolbar were actually windows. Since Microsoft Word 6.0 all buttons in the
> toolbar share only one window - the toolbar's one. That is the winning strategy -
> create usable components, without overloading the system. I am sure, if gtk
> minimizes the number of windows it uses, there will be a great
> increase in performances. In that case, your double buffering (if you
> are still sure we need it :-) will not be so expensive!
> 
> Maybe this letter is unrelated to this mailing list. Maybe it is too
> long and proposes a tons of dirty work in gtk developing (nobody likes
> that stuff:-).

Well, I've already mostly addressed the issues you seem to be worrying about
in GTK+-1.3, and I'd recommend you spend some time reading a Xlib
book like Adrian Nye's book or the Xlib manual to understand the
X drawing model, but leaving those points aside, this is a valid subject
on this list....

Regards,
                                        Owen