[Pharo-project] Drawing speed for animations?
Hello all, I am doing some smooth scrolling expriments. I use a step method in which I adjust the display. When I set stepTime to 0, the time between steps is still between 10 and 40 msces. During a scroll which takes 10 steps I see apx 1000 redraws of fairly simple Morphs. That is 100 redraws per step. When an average step takes apx. 20 msec this is 0.2 msec per redaw. Does this look normal, or should I hunt for flaws in my program? If this is the normal speed, then I cannot do animations in morphic, such that I get a new frame every 14 msec (70 Hz), at least not the way I am trying to do it. Another thing I cannot explain is the following: when I repeatedly call my step method from another method (putting a Delay between the calls), the display does not always update. I just see the end of the scroll, but not the steps in between. Only when I add a World displayWorld I see the intermediate scroll positions. However, when I call step from an explorer the Display updates just fine, without an explicit displayWorld. Why is that so? -- Martin
On 4 May 2012 17:50, Martin Drautzburg <Martin.Drautzburg@web.de> wrote:
Hello all,
I am doing some smooth scrolling expriments. I use a step method in which I adjust the display. When I set stepTime to 0, the time between steps is still between 10 and 40 msces. During a scroll which takes 10 steps I see apx 1000 redraws of fairly simple Morphs. That is 100 redraws per step. When an average step takes apx. 20 msec this is 0.2 msec per redaw. Does this look normal, or should I hunt for flaws in my program?
hard to say.. apparently every morph should be drawn only once per step. probably you mixing stepping and drawing/updating? during stepping you should change some state, like advance the counters, do some calculations etc.. and then _just_ invalidate morphs which need to be redrawn, but do not draw them directly. (use "self changed" for morph ) then morphic will take care about redrawing things which are changed.
If this is the normal speed, then I cannot do animations in morphic, such that I get a new frame every 14 msec (70 Hz), at least not the way I am trying to do it.
Another thing I cannot explain is the following: when I repeatedly call my step method from another method (putting a Delay between the calls), the display does not always update. I just see the end of the scroll, but not the steps in between. Only when I add a World displayWorld I see the intermediate scroll positions. However, when I call step from an explorer the Display updates just fine, without an explicit displayWorld. Why is that so?
because of deferred updates. you should use Display forceToScreen to actually update the display.
-- Martin
-- Best regards, Igor Stasenko.
On Friday, 4. May 2012 18:01:47 Igor Stasenko wrote:
hard to say.. apparently every morph should be drawn only once per step. probably you mixing stepping and drawing/updating?
during stepping you should change some state, like advance the counters, do some calculations etc.. and then _just_ invalidate morphs which need to be redrawn, but do not draw them directly.
Except for a few lines I don't draw anything myself. I just intercepted drawOn: in myMorphs so I could count the calls. Assuming each Morph is drawn once per step, the counts I get are plausible and I see that don't get redraws for morphs which are invisible. I just don't know if 0.2 msec for drawing a single morph is as good as its gets. It is several hundred thousand CPU cycles per Morph. Even when you assume 100 pixels per Morph, it is still a few thousand clock cycles for a single pixel. I made another test, where I just move 100 Morphs inside a Rectangle around. I got comparable speed, i.e. morphic was not always able to catch up with the screen refresh rate. In this case the movement was a lot faster when there was nothing else on the screen, when it moved over a Browser it slowed down quite a bit, which is understandable. My scrolling thingy however does not move across the whole screen, so morphic should have a bit less work. Invalidating: Do I invalide the Morph itself or its parent? If a Morph moves, the space it occupied before the move has to be redrawn too. Or do I invalidate it before and after the move? @Hilaire
And what about using PasteUpMorph with an unique step in the message taking care of the update of the submorphs?
What would be the advantage of doing this? Doesn't the "World" take care of updates well enough? -- Martin
On 4 May 2012 23:23, Martin Drautzburg <Martin.Drautzburg@web.de> wrote:
On Friday, 4. May 2012 18:01:47 Igor Stasenko wrote:
hard to say.. apparently every morph should be drawn only once per step. probably you mixing stepping and drawing/updating?
during stepping you should change some state, like advance the counters, do some calculations etc.. and then _just_ invalidate morphs which need to be redrawn, but do not draw them directly.
Except for a few lines I don't draw anything myself. I just intercepted drawOn: in myMorphs so I could count the calls. Assuming each Morph is drawn once  per step, the counts I get are plausible and I see that don't get redraws for morphs which are invisible.
I just don't know if 0.2 msec for drawing a single morph is as good as its gets. It is several hundred thousand CPU cycles per Morph. Even when you assume 100 pixels per Morph, it is still a few thousand clock cycles for a single pixel.
may i ask you, what is your plans? say, you want to implement a particle system which can be animated at decent frame rate, or something more complex? you know, there's always workarounds.. like in case of particles, instead of creating separate morphs for each of them, just use single morph and draw them in own #drawOn: method for morph which will represents your scene.. what i meant to say, that you don't have to stick with morphic , if you there some heavy number-crunching, or a lot of drawings per frame.
I made another test, where I just move 100 Morphs inside a Rectangle around. I got comparable speed, i.e. morphic was not always able to catch up with the screen refresh rate. In this case the movement was a lot faster when there was nothing else on the screen, when it moved over a Browser it slowed down quite a bit, which is understandable. My scrolling thingy however does not move across the whole screen, so morphic should have a bit less work.
Invalidating:
Do I invalide the Morph itself or its parent? If a Morph moves, the space it occupied before the move has to be redrawn too. Or do I invalidate it before and after the move?
i think if you using right method's to change morph's position, it should handle it automatically, so you don't have to worry about it by yourself. (see Morph>>position:)
@Hilaire
And what about using PasteUpMorph with an unique step in the message taking care of the update of the submorphs?
What would be the advantage of doing this? Doesn't the "World" take care of updates well enough?
-- Martin
-- Best regards, Igor Stasenko.
On Saturday, 5. May 2012 00:17:09 Igor Stasenko wrote:
may i ask you, what is your plans? say, you want to implement a particle system which can be animated at decent frame rate, or something more complex?
No much simpler. All I am doing is some sort of gantt chart. I thought smoth- scrolling would be cool, so I implemented it. But it just doesn't look as smooth as an iPad (but pretty smoth nontheless)
you know, there's always workarounds.. like in case of particles, instead of creating separate morphs for each of them, just use single morph and draw them in own #drawOn: method for morph which will represents your scene..
I had this idea initially too, but when I started to imangine, what I would have to write in my drawOn: method, I ended up with pretty much the same things, morphic is already doing. But actually my major concern is: do I still have a flaw in my program, i.e. is 0.2 msec per morph an acceptable value. If so, I will stop worrying. If not I will hunt for it. I am not complaining about morphic, I just want to know if an experienced programmer would settle for a less than 70 Hz framerate when moving around a few hundred Morphs?
On 5 May 2012 01:43, Martin Drautzburg <Martin.Drautzburg@web.de> wrote:
On Saturday, 5. May 2012 00:17:09 Igor Stasenko wrote:
may i ask you, what is your plans? say, you want to implement a particle system which can be animated at decent frame rate, or something more complex?
No much simpler. All I am doing is some sort of gantt chart. I thought smoth- scrolling would be cool, so I implemented it. But it just doesn't look as smooth as an iPad (but pretty smoth nontheless)
but you can cheat. look at ipad/imac zooming interface.. when you zoom in, it doesn't redraws the whole desktop each frame. it just captures screenshoot and zooms that image instead (with nice filtering of course).. and only when you stop zooming, it redraws everything at new scale. as for you, you can do the same, you can prerender a big bitmap in memory, and show only portion of it, while scrolling.
you know, there's always workarounds.. like in case of particles, instead of creating separate morphs for each of them, just use single morph and draw them in own #drawOn: method for morph which will represents your scene..
I had this idea initially too, but when I started to imangine, what I would have to write in my drawOn: method, I ended up with pretty much the same things, morphic is already doing.
But actually my major concern is: do I still have a flaw in my program, i.e. is 0.2 msec per morph an acceptable value. If so, I will stop worrying. If not I will hunt for it. I am not complaining about morphic, I just want to know if an experienced programmer would settle for a less than 70 Hz framerate when moving around a few hundred Morphs?
you should keep in mind that redrawing dozens of morphs involves checking a lot of extra conditions per morph, like visibility, clipping, calculating bounds etc etc etc which costs precious cycles. and which presumably you can easily avoid by having less heavyweight model for your scene. -- Best regards, Igor Stasenko.
On Saturday, 5. May 2012 02:38:11 Igor Stasenko wrote:
On 5 May 2012 01:43, Martin Drautzburg <Martin.Drautzburg@web.de> wrote:
On Saturday, 5. May 2012 00:17:09 Igor Stasenko wrote:
may i ask you, what is your plans? say, you want to implement a particle system which can be animated at decent frame rate, or something more complex?
No much simpler. All I am doing is some sort of gantt chart. I thought smoth- scrolling would be cool, so I implemented it. But it just doesn't look as smooth as an iPad (but pretty smoth nontheless)
but you can cheat. look at ipad/imac zooming interface.. when you zoom in, it doesn't redraws the whole desktop each frame. it just captures screenshoot and zooms that image instead (with nice filtering of course).. and only when you stop zooming, it redraws everything at new scale.
Where would I have to look, when I want to do somehting like this? I had some hope in CachingMorph and I replaced my smooth scrolling RectangleMorph with a CachingMorph, but that froze everything, so it is probably not as simple as that. -- Martin
On 5 May 2012 09:39, Martin Drautzburg <Martin.Drautzburg@web.de> wrote:
On Saturday, 5. May 2012 02:38:11 Igor Stasenko wrote:
On 5 May 2012 01:43, Martin Drautzburg <Martin.Drautzburg@web.de> wrote:
On Saturday, 5. May 2012 00:17:09 Igor Stasenko wrote:
may i ask you, what is your plans? say, you want to implement a particle system which can be animated at decent frame rate, or something more complex?
No much simpler. All I am doing is some sort of gantt chart. I thought smoth- scrolling would be cool, so I implemented it. But it just doesn't look as smooth as an iPad (but pretty smoth nontheless)
but you can cheat. look at ipad/imac zooming interface.. when you zoom in, it doesn't redraws the whole desktop each frame. it just captures screenshoot and zooms that image instead (with nice filtering of course).. and only when you stop zooming, it redraws everything at new scale.
Where would I have to look, when I want to do somehting like this? I had some hope in CachingMorph and I replaced my smooth scrolling RectangleMorph with a CachingMorph, but that froze everything, so it is probably not as simple as that.
i dont think there is something like that. what you need is to create a large Form and then draw your scene there. form := Form extent: ... depth:.. . canvas := form getCanvas. self drawFullSceneOn: canvas then you just use rendered result for drawing on screen: drawOn: canvas canvas drawImage: form at: self origin + scrollamount someething like that.
-- Martin
-- Best regards, Igor Stasenko.
On 05.05.2012 17:23, Igor Stasenko wrote:
On 5 May 2012 09:39, Martin Drautzburg<Martin.Drautzburg@web.de> wrote:
On Saturday, 5. May 2012 02:38:11 Igor Stasenko wrote:
On 5 May 2012 01:43, Martin Drautzburg<Martin.Drautzburg@web.de> wrote:
On Saturday, 5. May 2012 00:17:09 Igor Stasenko wrote:
may i ask you, what is your plans? say, you want to implement a particle system which can be animated at decent frame rate, or something more complex? No much simpler. All I am doing is some sort of gantt chart. I thought smoth- scrolling would be cool, so I implemented it. But it just doesn't look as smooth as an iPad (but pretty smoth nontheless) but you can cheat. look at ipad/imac zooming interface.. when you zoom in, it doesn't redraws the whole desktop each frame. it just captures screenshoot and zooms that image instead (with nice filtering of course).. and only when you stop zooming, it redraws everything at new scale. Where would I have to look, when I want to do somehting like this? I had some hope in CachingMorph and I replaced my smooth scrolling RectangleMorph with a CachingMorph, but that froze everything, so it is probably not as simple as that. i dont think there is something like that. what you need is to create a large Form and then draw your scene there.
form := Form extent: ... depth:.. . canvas := form getCanvas. There is, the Hand does this when you drag a morph. (minus the scaling) Probably not very well factored/reusable though :)
Cheers, Henry
Hello Try World addDefferedUIMessage: [morph step]. and run your full loop with delays in separated process 2012/5/4, Martin Drautzburg <Martin.Drautzburg@web.de>:
Hello all,
I am doing some smooth scrolling expriments. I use a step method in which I adjust the display. When I set stepTime to 0, the time between steps is still between 10 and 40 msces. During a scroll which takes 10 steps I see apx 1000 redraws of fairly simple Morphs. That is 100 redraws per step. When an average step takes apx. 20 msec this is 0.2 msec per redaw. Does this look normal, or should I hunt for flaws in my program?
If this is the normal speed, then I cannot do animations in morphic, such that I get a new frame every 14 msec (70 Hz), at least not the way I am trying to do it.
Another thing I cannot explain is the following: when I repeatedly call my step method from another method (putting a Delay between the calls), the display does not always update. I just see the end of the scroll, but not the steps in between. Only when I add a World displayWorld I see the intermediate scroll positions. However, when I call step from an explorer the Display updates just fine, without an explicit displayWorld. Why is that so?
-- Martin
And what about using PasteUpMorph with an unique step in the message taking care of the update of the submorphs? Hilaire Le 04/05/2012 17:50, Martin Drautzburg a écrit :
Hello all,
I am doing some smooth scrolling expriments. I use a step method in which I adjust the display. When I set stepTime to 0, the time between steps is still between 10 and 40 msces. During a scroll which takes 10 steps I see apx 1000 redraws of fairly simple Morphs. That is 100 redraws per step. When an average step takes apx. 20 msec this is 0.2 msec per redaw. Does this look normal, or should I hunt for flaws in my program?
If this is the normal speed, then I cannot do animations in morphic, such that I get a new frame every 14 msec (70 Hz), at least not the way I am trying to do it.
Another thing I cannot explain is the following: when I repeatedly call my step method from another method (putting a Delay between the calls), the display does not always update. I just see the end of the scroll, but not the steps in between. Only when I add a World displayWorld I see the intermediate scroll positions. However, when I call step from an explorer the Display updates just fine, without an explicit displayWorld. Why is that so?
-- Dr. Geo -- http://www.drgeo.eu
participants (5)
-
Denis Kudriashov -
Henrik Sperre Johansen -
Hilaire Fernandes -
Igor Stasenko -
Martin Drautzburg