Why is the squeak gui slow? New clues.

> Most of the time squeak is fast enough. Every so often the gui slows down to a crawl. The user moves the mouse around and the gui will not respond the way it did a moment ago. Movements feel spastic. The user overshoots the mark, moves back, over shoots again. Gradually learning to pause ...a...long...time...between...very...small...movements.
>
> I was recently trying to program some improvements and did something I think sheds a light on the reason.
>
> I was fooling with the handles for a star morph. There are only 6 of them. Currently they all are individual submorphs of the star itself. However it seemed it would simplify things if there was only one handle. The center handle would make a good holder for the other five.
>
> When I finally got that working I ran into the problem that I mentioned in the first paragraph. The mouse gui became extremely retarded (in the time sense). This is consistent with what happens if you should run a mouse over true type fonts or flash morphs. The event processing slows down till it is painful to adjust to.
>
> My previous thought was that only massive pixel processing (large amount of screen updates) would cause a gui slowdown. Now however I am beginning to realize that event dispatch must be a prime suspect as well.
>
> That's all the info I have at the moment. I pass this along incase someone has some confirming or alternate information.
>

> On 16 February 2010 20:38, Jerome Peace  
> <[hidden email]> wrote:
>> Most of the time squeak is fast enough. Every so often the gui  
>> slows down to a crawl. The user moves the mouse around and the gui  
>> will not respond the way it did a moment ago. Movements feel  
>> spastic. The user overshoots the mark, moves back, over shoots  
>> again. Gradually learning to  
>> pause ...a...long...time...between...very...small...movements.
>>
>> I was recently trying to program some improvements and did  
>> something I think sheds a light on the reason.
>>
>> I was fooling with the handles for a star morph. There are only 6  
>> of them. Currently they all are individual submorphs of the star  
>> itself. However it seemed it would simplify things if there was  
>> only one handle. The center handle would make a good holder for the  
>> other five.
>>
>> When I finally got that working I ran into the problem that I  
>> mentioned in the first paragraph. The mouse gui became extremely  
>> retarded (in the time sense). This is consistent with what happens  
>> if you should run a mouse over true type fonts or flash morphs. The  
>> event processing slows down till it is painful to adjust to.
>>
>> My previous thought was that only massive pixel processing (large  
>> amount of screen updates) would cause a gui slowdown. Now however I  
>> am beginning to realize that event dispatch must be a prime suspect  
>> as well.
>>
>> That's all the info I have at the moment. I pass this along incase  
>> someone has some confirming or alternate information.
>>
>
> My 2 cents.
> I played with morphic rendering code, where in my morph, all
> attributes like color, border and many others retrieved from
> dictionaries.
> I expected that it may cause a major slowdown, but then discovered
> that its not. It is slower of course, but not to the point, where it
> becomes noticeable. So, i suspecting that bottlenecks is hidden
> somewhere else.
>
> Another observation is, that if you open many windows, things become
> slower and slower , in linear progression.
> The fact is, that in browser windows, most time spent on rendering
> text (using highly complex Text & font rendering code).
> So, Text rendering is a major bottleneck. And if we want to make an
> improvements, we should attack this area.
>
>> Yours in curiosity and service, --Jerome Peace
>>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>

> On 16 February 2010 20:38, Jerome Peace <[hidden email]> wrote:
>> Most of the time squeak is fast enough. Every so often the gui slows down to a crawl. The user moves the mouse around and the gui will not respond the way it did a moment ago. Movements feel spastic. The user overshoots the mark, moves back, over shoots again. Gradually learning to pause ...a...long...time...between...very...small...movements.
>>
>> I was recently trying to program some improvements and did something I think sheds a light on the reason.
>>
>> I was fooling with the handles for a star morph. There are only 6 of them. Currently they all are individual submorphs of the star itself. However it seemed it would simplify things if there was only one handle. The center handle would make a good holder for the other five.
>>
>> When I finally got that working I ran into the problem that I mentioned in the first paragraph. The mouse gui became extremely retarded (in the time sense). This is consistent with what happens if you should run a mouse over true type fonts or flash morphs. The event processing slows down till it is painful to adjust to.
>>
>> My previous thought was that only massive pixel processing (large amount of screen updates) would cause a gui slowdown. Now however I am beginning to realize that event dispatch must be a prime suspect as well.
>>
>> That's all the info I have at the moment. I pass this along incase someone has some confirming or alternate information.
>>
>
> My 2 cents.
> I played with morphic rendering code, where in my morph, all
> attributes like color, border and many others retrieved from
> dictionaries.
> I expected that it may cause a major slowdown, but then discovered
> that its not. It is slower of course, but not to the point, where it
> becomes noticeable. So, i suspecting that bottlenecks is hidden
> somewhere else.
>
> Another observation is, that if you open many windows, things become
> slower and slower , in linear progression.
> The fact is, that in browser windows, most time spent on rendering
> text (using highly complex Text & font rendering code).
> So, Text rendering is a major bottleneck. And if we want to make an
> improvements, we should attack this area.
>
>> Yours in curiosity and service, --Jerome Peace
>>
>

> 2010/2/16 Igor Stasenko <[hidden email]>:
>> On 16 February 2010 20:38, Jerome Peace <[hidden email]> wrote:
>>> Most of the time squeak is fast enough. Every so often the gui slows down to a crawl. The user moves the mouse around and the gui will not respond the way it did a moment ago. Movements feel spastic. The user overshoots the mark, moves back, over shoots again. Gradually learning to pause ...a...long...time...between...very...small...movements.
>>>
>>> I was recently trying to program some improvements and did something I think sheds a light on the reason.
>>>
>>> I was fooling with the handles for a star morph. There are only 6 of them. Currently they all are individual submorphs of the star itself. However it seemed it would simplify things if there was only one handle. The center handle would make a good holder for the other five.
>>>
>>> When I finally got that working I ran into the problem that I mentioned in the first paragraph. The mouse gui became extremely retarded (in the time sense). This is consistent with what happens if you should run a mouse over true type fonts or flash morphs. The event processing slows down till it is painful to adjust to.
>>>
>>> My previous thought was that only massive pixel processing (large amount of screen updates) would cause a gui slowdown. Now however I am beginning to realize that event dispatch must be a prime suspect as well.
>>>
>>> That's all the info I have at the moment. I pass this along incase someone has some confirming or alternate information.
>>>
>>
>> My 2 cents.
>> I played with morphic rendering code, where in my morph, all
>> attributes like color, border and many others retrieved from
>> dictionaries.
>> I expected that it may cause a major slowdown, but then discovered
>> that its not. It is slower of course, but not to the point, where it
>> becomes noticeable. So, i suspecting that bottlenecks is hidden
>> somewhere else.
>>
>> Another observation is, that if you open many windows, things become
>> slower and slower , in linear progression.
>> The fact is, that in browser windows, most time spent on rendering
>> text (using highly complex Text & font rendering code).
>> So, Text rendering is a major bottleneck. And if we want to make an
>> improvements, we should attack this area.
>>
>>> Yours in curiosity and service, --Jerome Peace
>>>
>>
>
> You can also try the preferences>debug>debug show damage just in case...
> At least, it shows a problem with splitters (they invalidate the menu
> bar... probably they invalidate at 0@0)
> BTW doesn't splitters of minimized windows upset anybody ?
>

> Nicolas
>
>>
>> --
>> Best regards,
>> Igor Stasenko AKA sig.
>>
>>
>
>

> Most of the time squeak is fast enough. Every so often the gui slows down to a crawl. The user moves the mouse around and the gui will not respond the way it did a moment ago. Movements feel spastic. The user overshoots the mark, moves back, over shoots again. Gradually learning to pause ...a...long...time...between...very...small...movements.
>
> I was recently trying to program some improvements and did something I think sheds a light on the reason.
>
> I was fooling with the handles for a star morph. There are only 6 of them. Currently they all are individual submorphs of the star itself. However it seemed it would simplify things if there was only one handle. The center handle would make a good holder for the other five.
>
> When I finally got that working I ran into the problem that I mentioned in the first paragraph. The mouse gui became extremely retarded (in the time sense). This is consistent with what happens if you should run a mouse over true type fonts or flash morphs. The event processing slows down till it is painful to adjust to.
>
> My previous thought was that only massive pixel processing (large amount of screen updates) would cause a gui slowdown. Now however I am beginning to realize that event dispatch must be a prime suspect as well.
>
> That's all the info I have at the moment. I pass this along incase someone has some confirming or alternate information.
>
> Yours in curiosity and service, --Jerome Peace
>
>
>
>
>

> How about removing a bit of wasteful crap ? :)
>
> By default, all system windows having a thin 1-pixel wide shadow. It
> is hardly noticeable visually, but slows down things considerably:
>
> [ World fullDrawOn: (World assuredCanvas ) ] timeToRun 527
> World allMorphsDo: [:m | m hasDropShadow: false ]
> [ World fullDrawOn: (World assuredCanvas ) ] timeToRun  425
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
>

>
> On Tue, Feb 16, 2010 at 6:42 PM, Igor Stasenko <[hidden email]> wrote:
>> How about removing a bit of wasteful crap ? :)
>>
>> By default, all system windows having a thin 1-pixel wide shadow. It
>> is hardly noticeable visually, but slows down things considerably:
>>
>> [ World fullDrawOn: (World assuredCanvas ) ] timeToRun 527
>> World allMorphsDo: [:m | m hasDropShadow: false ]
>> [ World fullDrawOn: (World assuredCanvas ) ] timeToRun  425
>>
>>
>>
>> --
>> Best regards,
>> Igor Stasenko AKA sig.
>>
>>
>
>

> On 17 February 2010 06:42, Chris Muller <[hidden email]> wrote:
>> Wow, I never noticed those shadows.
>>
>> This is so "Squeak" wouldn't you say!?  Subtle (1 pixel!), refined
>> (because the designer still cared enough for the difference in look),
>> and, sorry to say, apparently slower!  :-/
>>
>> Hm, a 10-20% improvement in world drawing speed or a 1-pixel shadow?
>> I find it hard to not want to cash in those shadows..
>>
> Well, this inefficiency can be optimized by implementing clever
> #drawDropShadowOn: for system window
> to not use default implementation, which does ... well you can see
> what it does by issuing:
>
> World allMorphsDo: [:m | m drawDropShadowOn: World assuredCanvas ]
>

> So, we could have a cake, and eat it too (in shadow ;)
>
>>
>> On Tue, Feb 16, 2010 at 6:42 PM, Igor Stasenko <[hidden email]> wrote:
>>> How about removing a bit of wasteful crap ? :)
>>>
>>> By default, all system windows having a thin 1-pixel wide shadow. It
>>> is hardly noticeable visually, but slows down things considerably:
>>>
>>> [ World fullDrawOn: (World assuredCanvas ) ] timeToRun 527
>>> World allMorphsDo: [:m | m hasDropShadow: false ]
>>> [ World fullDrawOn: (World assuredCanvas ) ] timeToRun  425
>>>
>>>
>>>
>>> --
>>> Best regards,
>>> Igor Stasenko AKA sig.
>>>
>>>
>>
>>
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>