[etoys-dev] Fwd: Etoys-To-Go-4.0.2253-beta slow when a viewer is
richi.moran at gmail.com
Mon Aug 24 23:45:39 EDT 2009
Actually, commenting one line of the method is a nicer fix. I think it keeps
the expected behavior but it works faster.
"Make the receiver's height and width be harmonious with those of the
| container ht nav |
container _ self pasteUpMorph ifNil: [self currentWorld].
ht := (nav := ActiveWorld findA: SugarNavTab)
*"referent height: (container height - ht)."*
referent width: (referent width min: container width - self width).
referent top: container top + ht
I don't know why that line is so slow, though.
On Mon, Aug 24, 2009 at 11:29 PM, Ricardo Moran <richi.moran at gmail.com>wrote:
> I found that ViewerFlapTab #spanWorld is the responsible for the slow down.
> It is on the change set 2234viewerBeneath-sw. If I remove this method it
> starts working correctly.
> On Mon, Aug 24, 2009 at 5:44 PM, Bert Freudenberg <bert at freudenbergs.de>wrote:
>> On 24.08.2009, at 21:32, Karl Ramberg wrote:
>> On 2009-08-24 18:24, Ricardo Moran wrote:
>> How strange, I tried it some minutes ago in another machine with Ubuntu
>> 9.04 and it behaves exactly the same. And it is very noticeable if you make
>> a new project, draw a simple sketch, make a script with forward: 5 turn: 5,
>> change the tickRate to 100 and run. Then opening a viewer should slow down
>> the script, and keeping the mouse down on a button should make it go faster.
>> I see this on Windows as well, just clicking anywhere when a Viewer is
>> open will make the morph move faster.
>> In the non-dev image, clicking in an empty part of the world makes no
>> But e.g. bringing up a menu does. Even by keyboard (Cmd-Shift-W).
>> - Bert -
>> etoys-dev mailing list
>> etoys-dev at squeakland.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the etoys-dev