Morph speeds up stepping when grabbed

Hi!

I'm having some performance problems with morphs, I think.

I have made two morphs: first is the owner of the second and the second one is doing stepping with as little timeStep, as possible (1?). Still it's too slow.

When I click on the morph, the owner is being picked. While in the air, the step function for the submorph suddenly gets called very often and the animation is nice and fast.

What's the reason for that? How can I modify the morphs, so that I get faster animation, when morphs aren't grabbed? Is it because, while in the air, one morph or another gets different stepTime or the step method is called in a different way? Or maybe some part of the code is not being run resulting in less overhead?

Thanks for your help :)

cheers,
kropki

Did you set the "higherPerformance" preference?

- Bert -

On Dec 7, 2007, at 13:22 , kropki wrote:



_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners

Yes, no visible difference.

I'm beginning to be desperate: I can see squeak is able to run so much faster. It's suppose to be about rapid prototyping and not performance tuning, right? ;)

Bert Freudenberg wrote

Did you set the "higherPerformance" preference?

You could profile both cases. There must be a difference. (close all  
other morphs while you do that)

- Bert -

On Dec 7, 2007, at 19:47 , kropki wrote:



_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners

If it's doing 5.5fps instead of 5 fps when I turn on the higherPerformance, it makes no difference for the user. I'm after making it to run at 30fps, like it is when the morph is grabbed.

Maybe as a temporary workaround I could cheat the morph that it has been grabbed, but I can't find an easy way to do that without messing up the morphic...

Bert Freudenberg wrote

You could profile both cases. There must be a difference. (close all  
other morphs while you do that)

- Bert -

On Dec 7, 2007, at 19:47 , kropki wrote:

>
> Yes, no visible difference.
>
> I'm beginning to be desperate: I can see squeak is able to run so much
> faster. It's suppose to be about rapid prototyping and not performance
> tuning, right? ;)
>
>
> Bert Freudenberg wrote:
>>
>> Did you set the "higherPerformance" preference?
>>
>



_______________________________________________
Beginners mailing list
Beginners@lists.squeakfoundation.org
http://lists.squeakfoundation.org/mailman/listinfo/beginners

On Fri, Dec 07, 2007 at 04:22:17AM -0800, kropki wrote:
What are you doing in the step method? It sounds like whatever
the step method does is not initiating a redraw. You need to
call self changed in order to initiate a redraw.

also, what is stepTime set to?

--
Matthew Fulmer -- http://mtfulmer.wordpress.com/
Help improve Squeak Documentation: http://wiki.squeak.org/squeak/808
_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners

On Fri, Dec 07, 2007 at 01:30:33PM -0700, Matthew Fulmer wrote:
By the way, it isn't the step method that gets called a lot
while dragging, it is the drawOn: method. So, it seems the
stepping method is doing it's thing, but you only get to see it
if you redraw more often

I missed that it was set to 1 before. I don't think the
scheduler can really honor step times less than 30 or so. I
believe it tries, but there is usually too much other stuff to
do.

--
Matthew Fulmer -- http://mtfulmer.wordpress.com/
Help improve Squeak Documentation: http://wiki.squeak.org/squeak/808
_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners

> By the way, it isn't the step method that gets called a lot
> while dragging, it is the drawOn: method. So, it seems the
> stepping method is doing it's thing, but you only get to see it
> if you redraw more often

I wouldn't say that. One of my morphs gets moved by 1px every time the
step is called. Then there's a self changed call at the end of the
step. If I would be missing andy redraws, I would see the morph
jumping by few pixels at a time. Instead I see it move pixel by pixel,
just very slow.

> I missed that it was set to 1 before. I don't think the
> scheduler can really honor step times less than 30 or so. I
> believe it tries, but there is usually too much other stuff to
> do.

Actually I just got back to a quite old backup image of the game, and
it works quite fast with pretty the same things happening in the step
method. The most important thing is that there is no speed difference
whether I have the morph grabbed or not, which is so annoying in the
recent version.

Plus I can set stepTime to 10 and see it goes about 3 times faster
than when I set it to 30, so that's not an issue in this version.

I'l try to analyse the differences between the images...

On Dec 7, 2007, at 22:01 , kropki wrote:

> I'l try to analyse the differences between the images...

Did you close everything in the world first (shift-click helps)?

- Bert -


_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners

Bert Freudenberg wrote

Did you close everything in the world first (shift-click helps)?

Damn, that was it! Two class browsers and a workspace. Closed that, runs like hell. ;) Thanks for the hint, should have tried that, instead of diving into the morphic insides and checking message tallys.

It seems that the morph had higher priority in getting step method called (not drawOn - step), compared to the other morphs in the world, when it was grabbed. When it wasn't, the other morphs were getting the step   calls and system was skipping the poor guy. Am I right, more or less?