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