Hi Guys -
I noticed that briefly yesterday but did some more investigation today and it turns out that the tools in 3.9 have become *really* slow. And it's not just because of the TTF caching. I turned off TTFs completely and noticed that things were still slow and then I devised a little benchmark:
win := Browser openBrowser topView. win extent: 600@350. br := win model. br systemCategoryListIndex: 1. World doOneCycle. Transcript cr; show: [1 to: 10 do:[:i| br classListIndex: i. World doOneCycle. ]] timeToRun.
The interesting thing about this benchmark is that you can run it multiple times to "increase the load" by having more browsers on the screen. I only noticed this accidentally but it turns out to be the relevant part.
In 3.8 the above results in a sequence of Run 1: 598 msecs Run 2: 630 msecs Run 3: 683 msecs Run 4: 689 msecs So there is a little bit of slowdown when you add more browsers which is what I would expect (due to rounded corners triggering some extra overdraw, the additional structure etc).
In 3.9 however, we get the following: Run 1: 883 msecs Run 2: 1311 msecs Run 3: 1632 msecs Run 4: 2006 msecs After four runs, we need 2.5 times as long as the first run. Something is causing a tremendous overhead for any additional browser on the screen. This matches my experience though originally I had attributed that to the TTF problems but it seems the issue is way deeper than that. Any ideas what was changed in 3.9 that could cause that slowdown?
Cheers, - Andreas
Hi Andreas,
the reason will be in the gradient background of windows. The background is processed during every update now but the previous versions were more optimized. I have tried this test on Squeak 3.9 with Skylark theme (http://www.comtalk.net/Squeak/87) and it was without this slowdown and about two times faster (without TTF).
-- Pavel
On 10/21/06, Andreas Raab andreas.raab@gmx.de wrote:
Hi Guys -
I noticed that briefly yesterday but did some more investigation today and it turns out that the tools in 3.9 have become *really* slow. And it's not just because of the TTF caching. I turned off TTFs completely and noticed that things were still slow and then I devised a little benchmark:
win := Browser openBrowser topView. win extent: 600@350. br := win model. br systemCategoryListIndex: 1. World doOneCycle. Transcript cr; show: [1 to: 10 do:[:i| br classListIndex: i. World doOneCycle. ]] timeToRun.
The interesting thing about this benchmark is that you can run it multiple times to "increase the load" by having more browsers on the screen. I only noticed this accidentally but it turns out to be the relevant part.
In 3.8 the above results in a sequence of Run 1: 598 msecs Run 2: 630 msecs Run 3: 683 msecs Run 4: 689 msecs So there is a little bit of slowdown when you add more browsers which is what I would expect (due to rounded corners triggering some extra overdraw, the additional structure etc).
In 3.9 however, we get the following: Run 1: 883 msecs Run 2: 1311 msecs Run 3: 1632 msecs Run 4: 2006 msecs After four runs, we need 2.5 times as long as the first run. Something is causing a tremendous overhead for any additional browser on the screen. This matches my experience though originally I had attributed that to the TTF problems but it seems the issue is way deeper than that. Any ideas what was changed in 3.9 that could cause that slowdown?
Cheers,
- Andreas
Pavel Krivanek wrote:
the reason will be in the gradient background of windows. The background is processed during every update now but the previous versions were more optimized.
Good theory, but I don't think this is the problem. When I turn off both TTFs and gradients in 3.9 I still get something like here:
Run 1: 811 msecs Run 2: 1191 msecs Run 3: 1483 msecs Run 4: 1867 msecs
It's a little better but not significantly (and it still feels way too slow). BTW, if anyone wants to repeat the experiments, the changes that I did for this test were: * setting the window title font to a non-TTF (Accuny 14 in my case) * change SystemWindow>>gradientWithColor: to return just the color So I'm still at a loss what has changed to introduce that slowdown.
Hm ... let me try something. Oh, yes, now *that* would explain it. Turn on #debugShowDamage in 3.9 and watch how it redraws the entire screen almost every time you click anywhere in a browser. Ouch. No idea why that is but it sure explains the effect.
Cheers, - Andreas
On 10/21/06, Andreas Raab andreas.raab@gmx.de wrote:
Pavel Krivanek wrote:
the reason will be in the gradient background of windows. The background is processed during every update now but the previous versions were more optimized.
Good theory, but I don't think this is the problem. When I turn off both TTFs and gradients in 3.9 I still get something like here:
Run 1: 811 msecs Run 2: 1191 msecs Run 3: 1483 msecs Run 4: 1867 msecs
I was talking about experiments with the Skylark theme without TTF. There's no slowdown there, results on my laptop are
444 435 459 456 465
Skylark theme uses old-time approach to window rendering...
It's a little better but not significantly (and it still feels way too slow). BTW, if anyone wants to repeat the experiments, the changes that I did for this test were:
- setting the window title font to a non-TTF (Accuny 14 in my case)
- change SystemWindow>>gradientWithColor: to return just the color
So I'm still at a loss what has changed to introduce that slowdown.
Hm ... let me try something. Oh, yes, now *that* would explain it. Turn on #debugShowDamage in 3.9 and watch how it redraws the entire screen almost every time you click anywhere in a browser. Ouch. No idea why that is but it sure explains the effect.
Cheers,
- Andreas
-- Pavel
Andreas Raab skrev:
Pavel Krivanek wrote:
the reason will be in the gradient background of windows. The background is processed during every update now but the previous versions were more optimized.
Good theory, but I don't think this is the problem. When I turn off both TTFs and gradients in 3.9 I still get something like here:
Run 1: 811 msecs Run 2: 1191 msecs Run 3: 1483 msecs Run 4: 1867 msecsIt's a little better but not significantly (and it still feels way too slow). BTW, if anyone wants to repeat the experiments, the changes that I did for this test were:
- setting the window title font to a non-TTF (Accuny 14 in my case)
- change SystemWindow>>gradientWithColor: to return just the color
So I'm still at a loss what has changed to introduce that slowdown.
Hm ... let me try something. Oh, yes, now *that* would explain it. Turn on #debugShowDamage in 3.9 and watch how it redraws the entire screen almost every time you click anywhere in a browser. Ouch. No idea why that is but it sure explains the effect.
Commenting out some code in BrowserCommentTextMorph reduces the bogus invalidation, so we have to debug the class BrowserCommentTextMorph to see what make it behave so bad. Karl
karl skrev:
Andreas Raab skrev:
Pavel Krivanek wrote:
the reason will be in the gradient background of windows. The background is processed during every update now but the previous versions were more optimized.
Good theory, but I don't think this is the problem. When I turn off both TTFs and gradients in 3.9 I still get something like here:
Run 1: 811 msecs Run 2: 1191 msecs Run 3: 1483 msecs Run 4: 1867 msecsIt's a little better but not significantly (and it still feels way too slow). BTW, if anyone wants to repeat the experiments, the changes that I did for this test were:
- setting the window title font to a non-TTF (Accuny 14 in my case)
- change SystemWindow>>gradientWithColor: to return just the color
So I'm still at a loss what has changed to introduce that slowdown.
Hm ... let me try something. Oh, yes, now *that* would explain it. Turn on #debugShowDamage in 3.9 and watch how it redraws the entire screen almost every time you click anywhere in a browser. Ouch. No idea why that is but it sure explains the effect.
Commenting out some code in BrowserCommentTextMorph reduces the bogus invalidation, so we have to debug the class BrowserCommentTextMorph to see what make it behave so bad. Karl
I tracked the issue down to SystemWindows>>addPaneSplitters which removes and adds pane splitters when the comment pane is added to the bottom of the browser. I'm not sure how to fix the issue, maybe hiding and showing the pane is better than deleting and reinstalling it. The root cause of the problem seem to be Morph>>privateAddMorph:atIndex: which do a lot of invaliditation that cause a massive redraw when it's sent. Karl
karl skrev:
karl skrev:
Andreas Raab skrev:
Pavel Krivanek wrote:
the reason will be in the gradient background of windows. The background is processed during every update now but the previous versions were more optimized.
Good theory, but I don't think this is the problem. When I turn off both TTFs and gradients in 3.9 I still get something like here:
Run 1: 811 msecs Run 2: 1191 msecs Run 3: 1483 msecs Run 4: 1867 msecsIt's a little better but not significantly (and it still feels way too slow). BTW, if anyone wants to repeat the experiments, the changes that I did for this test were:
- setting the window title font to a non-TTF (Accuny 14 in my case)
- change SystemWindow>>gradientWithColor: to return just the color
So I'm still at a loss what has changed to introduce that slowdown.
Hm ... let me try something. Oh, yes, now *that* would explain it. Turn on #debugShowDamage in 3.9 and watch how it redraws the entire screen almost every time you click anywhere in a browser. Ouch. No idea why that is but it sure explains the effect.
Commenting out some code in BrowserCommentTextMorph reduces the bogus invalidation, so we have to debug the class BrowserCommentTextMorph to see what make it behave so bad. Karl
I tracked the issue down to SystemWindows>>addPaneSplitters which removes and adds pane splitters when the comment pane is added to the bottom of the browser. I'm not sure how to fix the issue, maybe hiding and showing the pane is better than deleting and reinstalling it. The root cause of the problem seem to be Morph>>privateAddMorph:atIndex: which do a lot of invaliditation that cause a massive redraw when it's sent. Karl
BorderedMorph wanted more specific position of the morphs added, otherwise they would be added to the top left corner. Hope this cures it :-)
Karl
In 3.9 however, we get the following: Run 1: 883 msecs Run 2: 1311 msecs Run 3: 1632 msecs Run 4: 2006 msecs After four runs, we need 2.5 times as long as the first run. Something is
Andreas,
that would be my 2 second delay. I do like to have a few windows open. Now if your machine is 3x as powerful as mine which is quite likely then that would be my problem
thanks for looking into it
best regards
Keith Send instant messages to your online friends http://uk.messenger.yahoo.com
I took some images and did not change anything, here are some of the results I got.
7033 3839 5494 6628
7000 5769 7698 9422 10554
seems that in between we got something...
6720 3767 5295 4924 5900 5788 5936 5264 here it seems that when the widgets are really overlapping the behavior is different.
6696 5197 5597 7928 6833 8845
6678 4192 2741 2691 4326 4406
Not the solution but I noticed that in RC3 there is pretty often and regularly a complete display redraw just when selecting a different class.
squeak-dev@lists.squeakfoundation.org
-
Andreas Raab -
karl -
Keith Hodges -
Pavel Krivanek -
stephane ducasse