Re: Some performance notes

[Hans Breuer <hans breuer org>]

At 09:30 14.08.01 -0400, Owen Taylor wrote:
>
>Pavel Machek <pavel ucw cz> writes:
>
>> Hi!
>> 
>> > Generally, on my tests on a 400mhz celeron I felt fairly good about
>> > the overall performance with debugging off. Opaque resizing was a
>> > little more sluggish than I would like, but other operations seemed
>> > pretty snappy, and it would definitely have been useable on a slower
>> > machine.
>> 
>> Note that this is pretty bad. Eating 100% cpu of 400MHz celeron for GUI
>> is not too good. You should eat 10%... [win95 was usable on 386/40, 4MB]
>
>Errr, we aren't talking about just sitting there. We are talking
>about opaque resizing. Slower machine == 100% cpu at lower framerate.
>
Why not: Every single processor machine == 100% cpu while opaque resizing ?
But if you read my prevoius mail to the same subject, you may agree that
the over all performance penalty of double buffering is about ~10-20%
(up to 30% on win32) if one only counts the additional indirection 
through the backing pixmaps. And it is there on every drawing.

After applying my --gtk-unbuffered patch on Linux I got this impression
(--bench) but also understood why it isn't such simple to disable 
double-buffering. The main problem I saw was "scrolling" layout leaving
garbage background, which it doesn't yet on win32. Probably just some 
bug in the Invalidation code on win32 :-)

The only other really annoying feature with --gtk-unbuffered was massive
flicker with the color selector. But this one should be simply fixeable 
by setting the right clip region for clearing the background. 

This would be really easy to implement (on win32) if two additional
region functions would be added:

gdk_region_polygon
gdk_region_ellipse

>And if you have a slow machine, then you shouldn't be using opaque
>resizing.
>
Agreed. 

>And no, GTK+-2.0 isn't going to be useable on a 386/40. (Frankly,
>I don't really think Win95 was that pleasant either on such a
>machine running real apps.)
>
But a 486/DX 100, 16 MB was ok for win95 :-)

>There are tradeoffs between the feature set, the ease of programming
>and speed, and I have no intention of making that tradeoff
>based on machines that have been obsolete for a decade.
>
Frankly it is mostly a political decision. If the intention is to
make a computer update necessary, when updateing to Gtk+2.0 that would
be ok, too. (But some bundling/pre-installing like Micro$oft does would 
it make easier to accept :-)

IMHO it would be nice to have at least the goal to get Gtk+2.0's
visual appearance concerning performance close to the one of
Gtk+ 1.2. I think it isn't such far away if the right people
are willing to tweak performance ...

And the ability to reduce run-time memory requirements may be nice
as well, aka. --gtk-unbuffered ...

Regards,
	Hans
-------- Hans "at" Breuer "dot" Org -----------
Tell me what you need, and I'll tell you how to 
get along without it.                -- Dilbert