Re: Avoiding flickering

[Ivan Popivanov <popivan gmx net>]

Owen Taylor wrote:
> 
> The reason why widgets in GTK+-1.2 are cleared long before they are
> redrawn is because of window gravity, that's all.
First of all, I want to apologies - the reason for the redrawing is
really the Gravity bit! Before writing the previous message I took a
look in a couple of books (including Adrian Nye's book and the Xlib
manual) but no one describes in details the way the server redraws the
windows. So, I wrote a small program just to figure out, what is going.
Unfortunately, there was an error in my code so my conclusions were
erroneous. Anyway, it seems that windows is not so clever in redrawing
as X is, so I hope that the things with the Gravity and window clearing
will be fixed in the new version of Gtk and that will be end of the
story.

> 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.
You use only one pixmap? Great! Are all of the gdk calls blocking? If they

are not (as I suppose), how the synchronization for multi-threaded
application is done, assuming that the gdk calls are not blocking?

> 
> 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.
Mmm, I do not have much Qt experience - I do not like it, but as I 
mentioned Gtk uses much more windows than Windows does. If you are 
comparing gtk against, say Xaw, I think it is a little bit outdated :-)

> Do you have any particular reason to think that these are a 
> performance problem.
I believe they are. The knowledge what for you need a window is private
to your application and it is the best place to handle the mouse position!

Therefor I see now reason to create a window just to care about
leave/enter messages (toolbar buttons do not need much more window
specific job).
Anyway, if it is not so obvious to you, I will be kind enough to not
advising you to spend some time reading books or papers. How many books do you
think cover the topic?

> The CList flickers a lot, yes. That has very little to do with general
> drawing in GTK+.
CTree also, because it inherits CList...And If I give you another
example the problem will be with the widget I use, I guess. 
I was very annoyed discovering that gedit flickers on every file
save!!!  This has nothing to do with gtk, of course, has it ;-)

There was a discussion about concerning comparison between gtk and other
toolkits. I want to mention that I am speaking of "performances" that you
can perceive using only your own eyes as a measure. Until recently, I have
been using a 486 with 36Mb of RAM for three years. Believe you or not, I have
been running Windows NT 4 (Workstation) on this box! It works fine. I also
run Linux - it also runs fine. When I run graphical user interface under
linux - nightmare. If I run only gnome (with the default Enlightenment) the
system was almost unuseful. I removed the Enlightenment (an awful application.
This window manager itself eats tons of memory. ) the
thinks get better, but still there was no comparison with Windows.
Even if I had had a more powerful configuration I did not agree to
devote the resources of a whole 486 box only to the GUI. On the same
machine I run Explorer 5, with its nice drawing, smooth & animation scrolling
controls and I could not run a single GUI application under Linux! I claim that
Linux kernel is faster than the Windows' one. I believe that the X server
is also reasonable comparable to Windows'.
The developers are giving their best to write GUI applications.
So where is the problem?
My answer: no fast enough & features reach GUI library.

I am sure, next gtk will clear a lot of drawbacks, but in order to have
nice GUI applications the GUI library should be optimized as much as
possible (say as the kernel is) and every desktop system needs GUI applications.

So, think about not reinventing the whole wheel, but just using the
experience of other peolpe.


        Ivan

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