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