Re: Avoiding flickering

[Ivan Popivanov <popivan gmx net>]

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. 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,
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! 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, 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.

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.

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:-). If this is the case - just let me know and I'll stop
sending such kind of letters. I am just trying to help. In my opinion,
gtk is the only graphical API, that can evolve in the UNIX equivalent to
Windows GUI - both in features and performances.

        Ivan

-- 
Sent through Global Message Exchange - http://www.gmx.net