I was just testing and I noticed something weird: I have a script running at 100 ticks per second, then I open a viewer and the script slows down, then I click in the viewer title and keep the mouse down and the script starts running faster! It also happens if I keep the mouse down in any of the buttons of the sugar flap or the viewer. In fact, it also happens if I drag a button out of the Supplies flap and I keep the mouse down on it. I hope this helps fixing the problem.
Cheers.
On Sun, Aug 23, 2009 at 12:36 PM, Ricardo Moran richi.moran@gmail.comwrote:
I've just tried the Etoys-latest-Beta-ToGo on Windows and I noticed that the car script in the clouds project gets slower when I open a viewer. This also happens with any other script with a ticking rate greater than 25. I don't know what is causing this but it used to work in earlier versions: I've tried Squeakland-OLPC 2177, etoys3.1 update 2177, etoys4.0 update 2192 and neither of the above have this problem. I don't know if this also happens in Linux or Mac os.
Can't reproduce on a Mac. Yes it slows down when a viewer is opened, but clicking the mouse anywhere does not appear to make a speed difference.
- Bert -
On 23.08.2009, at 17:56, Ricardo Moran wrote:
I was just testing and I noticed something weird: I have a script running at 100 ticks per second, then I open a viewer and the script slows down, then I click in the viewer title and keep the mouse down and the script starts running faster! It also happens if I keep the mouse down in any of the buttons of the sugar flap or the viewer. In fact, it also happens if I drag a button out of the Supplies flap and I keep the mouse down on it. I hope this helps fixing the problem.
Cheers.
On Sun, Aug 23, 2009 at 12:36 PM, Ricardo Moran richi.moran@gmail.com wrote: I've just tried the Etoys-latest-Beta-ToGo on Windows and I noticed that the car script in the clouds project gets slower when I open a viewer. This also happens with any other script with a ticking rate greater than 25. I don't know what is causing this but it used to work in earlier versions: I've tried Squeakland-OLPC 2177, etoys3.1 update 2177, etoys4.0 update 2192 and neither of the above have this problem. I don't know if this also happens in Linux or Mac os.
etoys-dev mailing list etoys-dev@squeakland.org http://lists.squeakland.org/mailman/listinfo/etoys-dev
I think this is a bug, it didn't use to slow down in earlier versions. I will try to find out what could have changed since etoys4.0 2192 to produce this error.
On Sun, Aug 23, 2009 at 6:13 PM, Bert Freudenberg bert@freudenbergs.dewrote:
Can't reproduce on a Mac. Yes it slows down when a viewer is opened, but clicking the mouse anywhere does not appear to make a speed difference.
- Bert -
On 23.08.2009, at 17:56, Ricardo Moran wrote:
I was just testing and I noticed something weird: I have a script running at 100 ticks per second, then I open a viewer and the script slows down, then I click in the viewer title and keep the mouse down and the script starts running faster! It also happens if I keep the mouse down in any of the buttons of the sugar flap or the viewer. In fact, it also happens if I drag a button out of the Supplies flap and I keep the mouse down on it. I hope this helps fixing the problem.
Cheers.
On Sun, Aug 23, 2009 at 12:36 PM, Ricardo Moran richi.moran@gmail.comwrote:
I've just tried the Etoys-latest-Beta-ToGo on Windows and I noticed that the car script in the clouds project gets slower when I open a viewer. This also happens with any other script with a ticking rate greater than 25. I don't know what is causing this but it used to work in earlier versions: I've tried Squeakland-OLPC 2177, etoys3.1 update 2177, etoys4.0 update 2192 and neither of the above have this problem. I don't know if this also happens in Linux or Mac os.
etoys-dev mailing list etoys-dev@squeakland.org http://lists.squeakland.org/mailman/listinfo/etoys-dev
etoys-dev mailing list etoys-dev@squeakland.org http://lists.squeakland.org/mailman/listinfo/etoys-dev
On Sunday 23 Aug 2009 9:26:21 pm Ricardo Moran wrote:
I was just testing and I noticed something weird: I have a script running at 100 ticks per second, then I open a viewer and the script slows down, then I click in the viewer title and keep the mouse down and the script starts running faster!
I didn't see this effect on the Linux (Kubuntu 9.04). You may want to turn on dot-style pen trails to capture the behavior.
Subbu
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.
On Sun, Aug 23, 2009 at 11:12 PM, K. K. Subramaniam subbukk@gmail.comwrote:
On Sunday 23 Aug 2009 9:26:21 pm Ricardo Moran wrote:
I was just testing and I noticed something weird: I have a script running at 100 ticks per second, then I open a viewer and the script slows down, then I click in the viewer title and keep the mouse down and the script starts running faster!
I didn't see this effect on the Linux (Kubuntu 9.04). You may want to turn on dot-style pen trails to capture the behavior.
Subbu
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.
Karl
On Sun, Aug 23, 2009 at 11:12 PM, K. K. Subramaniam <subbukk@gmail.com mailto:subbukk@gmail.com> wrote:
On Sunday 23 Aug 2009 9:26:21 pm Ricardo Moran wrote: > I was just testing and I noticed something weird: I have a script running > at 100 ticks per second, then I open a viewer and the script slows down, > then I click in the viewer title and keep the mouse down and the script > starts running faster! I didn't see this effect on the Linux (Kubuntu 9.04). You may want to turn on dot-style pen trails to capture the behavior. Subbu
etoys-dev mailing list etoys-dev@squeakland.org http://lists.squeakland.org/mailman/listinfo/etoys-dev
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 difference.
But e.g. bringing up a menu does. Even by keyboard (Cmd-Shift-W).
- Bert -
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@freudenbergs.dewrote:
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 difference.
But e.g. bringing up a menu does. Even by keyboard (Cmd-Shift-W).
- Bert -
etoys-dev mailing list etoys-dev@squeakland.org http://lists.squeakland.org/mailman/listinfo/etoys-dev
Actually, commenting one line of the method is a nicer fix. I think it keeps the expected behavior but it works faster.
spanWorld "Make the receiver's height and width be harmonious with those of the container."
| container ht nav | container _ self pasteUpMorph ifNil: [self currentWorld]. ht := (nav := ActiveWorld findA: SugarNavTab) ifNotNil: [nav height] ifNil: [0]. *"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. Cheers. Richo
On Mon, Aug 24, 2009 at 11:29 PM, Ricardo Moran richi.moran@gmail.comwrote:
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@freudenbergs.dewrote:
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 difference.
But e.g. bringing up a menu does. Even by keyboard (Cmd-Shift-W).
- Bert -
etoys-dev mailing list etoys-dev@squeakland.org http://lists.squeakland.org/mailman/listinfo/etoys-dev
Thank you, Ricardo, for tracking down and fixing this serious performance bug!
The fix has been promptly pushed to the etoys4.0 update stream, as update 2255viewerSpanFix-rm.
-- Scott
On Aug 24, 2009, at 8:45 PM, Ricardo Moran wrote:
Actually, commenting one line of the method is a nicer fix. I think it keeps the expected behavior but it works faster.
spanWorld "Make the receiver's height and width be harmonious with those of the container."
| container ht nav | container _ self pasteUpMorph ifNil: [self currentWorld]. ht := (nav := ActiveWorld findA: SugarNavTab) ifNotNil: [nav height] ifNil: [0]. "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. Cheers. Richo
On Mon, Aug 24, 2009 at 11:29 PM, Ricardo Moran richi.moran@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@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 difference.
But e.g. bringing up a menu does. Even by keyboard (Cmd-Shift-W).
- Bert -
etoys-dev mailing list etoys-dev@squeakland.org http://lists.squeakland.org/mailman/listinfo/etoys-dev
etoys-dev mailing list etoys-dev@squeakland.org http://lists.squeakland.org/mailman/listinfo/etoys-dev
I'm glad I helped :)
On Tue, Aug 25, 2009 at 1:44 AM, Scott Wallace <scott.wallace@squeakland.org
wrote:
Thank you, Ricardo, for tracking down and fixing this serious performance bug!
The fix has been promptly pushed to the etoys4.0 update stream, as update 2255viewerSpanFix-rm.
-- Scott
On Aug 24, 2009, at 8:45 PM, Ricardo Moran wrote:
Actually, commenting one line of the method is a nicer fix. I think it
keeps the expected behavior but it works faster.
spanWorld "Make the receiver's height and width be harmonious with those of the container."
| container ht nav | container _ self pasteUpMorph ifNil: [self currentWorld]. ht := (nav := ActiveWorld findA: SugarNavTab) ifNotNil: [nav height] ifNil: [0]. "referent height: (container height - ht)." referent width: (referent width min: container width - self width). referent top: container top + htI don't know why that line is so slow, though. Cheers. Richo
On Mon, Aug 24, 2009 at 11:29 PM, Ricardo Moran richi.moran@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@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 difference.
But e.g. bringing up a menu does. Even by keyboard (Cmd-Shift-W).
- Bert -
etoys-dev mailing list etoys-dev@squeakland.org http://lists.squeakland.org/mailman/listinfo/etoys-dev
etoys-dev mailing list etoys-dev@squeakland.org http://lists.squeakland.org/mailman/listinfo/etoys-dev
Hi all,
Make sure to create issues in the tracker for any bugs & fixes. This helps us make release notes, etc. (Not sure if this was done, just making the larger point anyway.)
Tim
On Aug 25, 2009, at 12:44 AM, Scott Wallace wrote:
Thank you, Ricardo, for tracking down and fixing this serious performance bug!
The fix has been promptly pushed to the etoys4.0 update stream, as update 2255viewerSpanFix-rm.
-- Scott
On Aug 24, 2009, at 8:45 PM, Ricardo Moran wrote:
Actually, commenting one line of the method is a nicer fix. I think it keeps the expected behavior but it works faster.
spanWorld "Make the receiver's height and width be harmonious with those of the container."
| container ht nav | container _ self pasteUpMorph ifNil: [self currentWorld]. ht := (nav := ActiveWorld findA: SugarNavTab) ifNotNil: [nav height] ifNil: [0]. "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. Cheers. Richo
On Mon, Aug 24, 2009 at 11:29 PM, Ricardo Moran <richi.moran@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@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 difference.
But e.g. bringing up a menu does. Even by keyboard (Cmd-Shift-W).
- Bert -
etoys-dev mailing list etoys-dev@squeakland.org http://lists.squeakland.org/mailman/listinfo/etoys-dev
etoys-dev mailing list etoys-dev@squeakland.org http://lists.squeakland.org/mailman/listinfo/etoys-dev
etoys-dev mailing list etoys-dev@squeakland.org http://lists.squeakland.org/mailman/listinfo/etoys-dev
Ah. That did reproduce the problem. I was testing on the bouncing car in the cloud project before.
To verify, you can get out a frame rate display from the object catalog.
On my Mac I get the regular 50 fps animating a simple sketch. Opening its viewer gets down to 25 fps. Holding the mouse button down on Button or the Viewer's title bar indeed gets the rate back up to 50. How strange.
I cannot reproduce the same on the car in the cloud project. It slows down the same but does not speed up pressing a button.
However, when I paint a new sketch in the clouds project, the odd behavior returns - as long as the car script is not ticking.
The higherPerformance preference makes no substantial difference except that the 50 fps cap is removed.
- Bert -
On 24.08.2009, at 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.
On Sun, Aug 23, 2009 at 11:12 PM, K. K. Subramaniam subbukk@gmail.com wrote: On Sunday 23 Aug 2009 9:26:21 pm Ricardo Moran wrote:
I was just testing and I noticed something weird: I have a script
running
at 100 ticks per second, then I open a viewer and the script slows
down,
then I click in the viewer title and keep the mouse down and the
script
starts running faster!
I didn't see this effect on the Linux (Kubuntu 9.04). You may want to turn on dot-style pen trails to capture the behavior.
Subbu
etoys-dev mailing list etoys-dev@squeakland.org http://lists.squeakland.org/mailman/listinfo/etoys-dev
etoys-dev@lists.squeakfoundation.org
-
Bert Freudenberg -
K. K. Subramaniam -
Karl Ramberg -
Ricardo Moran -
Scott Wallace -
Timothy Falconer