[FIX]Re: BrowserCommentTextMorph Re: 3.9 browser speed

karl karl.ramberg at chello.se
Sun Nov 5 21:21:58 UTC 2006

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 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
BorderedMorph wanted more specific position of the morphs added, 
otherwise they would be added to the top left corner. Hope this cures it :-)


-------------- next part --------------
A non-text attachment was scrubbed...
Name: BorderedMorph.kfr.2.cs.gz
Type: application/x-gzip
Size: 974 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20061105/c267c63f/BorderedMorph.kfr.2.cs.bin

More information about the Squeak-dev mailing list