Max CPU usage when #drawOn: is overridden
Locked
 
|
If we override #drawOn: and implement custom logic to draw.. every few milliseconds as it gets called the CPU usage shoots to available max.. Run four instances of the same class that overrides and does some moderately complex draw routine of say : CircleMorph with border set, few lines, color rendering..
I will send in the .st file later .. that can be tested against.. Is this expected or what are the ways to avoid this CPU overhead... NativeBoost animation, far more responsive.. also goes up very similarly. but little more tolerable... VGTigerMorph... more so than FlakesDemo... |
|
|
As an screenshot should explain it better..
This is now pushing the CPU to 66 - 90%+ almost all the time.. and as the top hogger of CPU constantly.. Not having VGTigerDemo does not alter it much.. so its not NativeBoost at fault per se..
Kill the clock and the VGTiger it comes down to a nice 4% CPU
On Tue, Sep 4, 2012 at 7:08 PM, S Krish <[hidden email]> wrote:
|
Pharo_Animation.png (459K) 
Re: Max CPU usage when #drawOn: is overridden
|
|
On 4 September 2012 16:18, S Krish <[hidden email]> wrote:
> As an screenshot should explain it better.. > > This is now pushing the CPU to 66 - 90%+ almost all the time.. and as the > top hogger of CPU constantly.. > hmm, what did you expected there? Cairo uses CPU for rendering. It is faster than balloon, must faster but sure thing if you run animation which renders new frame as soon as it finished previous one, it will consume full available CPU resources. > Not having VGTigerDemo does not alter it much.. so its not NativeBoost at > fault per se.. > > Kill the clock and the VGTiger it comes down to a nice 4% CPU > > On Tue, Sep 4, 2012 at 7:08 PM, S Krish <[hidden email]> > wrote: >> >> >> >> If we override #drawOn: and implement custom logic to draw.. every few >> milliseconds as it gets called the CPU usage shoots to available max.. >> >> Run four instances of the same class that overrides and does some >> moderately complex draw routine of say : CircleMorph with border set, few >> lines, color rendering.. >> >> I will send in the .st file later .. that can be tested against.. >> >> >> Is this expected or what are the ways to avoid this CPU overhead... >> >> >> NativeBoost animation, far more responsive.. also goes up very similarly. >> but little more tolerable... VGTigerMorph... more so than FlakesDemo... >> >> >> > -- Best regards, Igor Stasenko. |
Re: Max CPU usage when #drawOn: is overridden
|
|
and if you don't want to run animation,
do not use #startStepping method. On 5 September 2012 00:06, Igor Stasenko <[hidden email]> wrote: > On 4 September 2012 16:18, S Krish <[hidden email]> wrote: >> As an screenshot should explain it better.. >> >> This is now pushing the CPU to 66 - 90%+ almost all the time.. and as the >> top hogger of CPU constantly.. >> > hmm, what did you expected there? Cairo uses CPU for rendering. It is > faster than balloon, must faster > but sure thing if you run animation which renders new frame as soon as > it finished previous one, > it will consume full available CPU resources. > > >> Not having VGTigerDemo does not alter it much.. so its not NativeBoost at >> fault per se.. >> >> Kill the clock and the VGTiger it comes down to a nice 4% CPU >> > > > > >> On Tue, Sep 4, 2012 at 7:08 PM, S Krish <[hidden email]> >> wrote: >>> >>> >>> >>> If we override #drawOn: and implement custom logic to draw.. every few >>> milliseconds as it gets called the CPU usage shoots to available max.. >>> >>> Run four instances of the same class that overrides and does some >>> moderately complex draw routine of say : CircleMorph with border set, few >>> lines, color rendering.. >>> >>> I will send in the .st file later .. that can be tested against.. >>> >>> >>> Is this expected or what are the ways to avoid this CPU overhead... >>> >>> >>> NativeBoost animation, far more responsive.. also goes up very similarly. >>> but little more tolerable... VGTigerMorph... more so than FlakesDemo... >>> >>> >>> >> > > > > -- > Best regards, > Igor Stasenko. -- Best regards, Igor Stasenko. |
|
|
In reply to this post by Igor Stasenko
TestAnimationClock #drawOn: aCanvas I have to dig in a bit more.. is the issue here.. not NB/ VGTigerDemo.
Normally all of Morphic rendering is I presume , premised on the invocation of this method recursively on all submorphs till all of them are rendered.. for all morphs on screen.
TestAnimationClockPanel: Also I have a similar override.. and it does not give me any overhead.. though all it has is one Text.. string. Why should only Clock have such an overhead.. : is because of calculating the hour/minute/hand vector .. ?
Will dig in more and try to understand this for optimizations. ********** PS: I am not using the startStepping / stop.. mechanism as yet in these..
Maybe I am naive.. about presuming..
On Wed, Sep 5, 2012 at 3:36 AM, Igor Stasenko <[hidden email]> wrote:
|
Re: Max CPU usage when #drawOn: is overridden
|
|
Stepping methods are called in the main UI thread but they aren't
drawing anything. Then, what is the default cycle? Have a look at MorphicUIManager for answers, especially spawnNewProcess, which basically does this: spawnNewProcess UIProcess := [ [World doOneCycle. Processor yield. false] whileFalse: []. ] newProcess priority: Processor userSchedulingPriority. UIProcess resume World doOneCycle and the userSchedulingPriority are at play here. This will lead us to WorldState >> doOneCycleFor: aWorld "Do one cycle of the interaction loop. This method is called repeatedly when the world is running. This is a moderately private method; a better alternative is usually either to wait for events or to check the state of things from #step methods." self interCyclePause: MinCycleLapse. self doOneCycleNowFor: aWorld. And, yeah, here it is: WorldState >> interCyclePause: milliSecs "delay enough that the previous cycle plus the amount of delay will equal milliSecs. If the cycle is already expensive, then no delay occurs. However, if the system is idly waiting for interaction from the user, the method will delay for a proportionally long time and cause the overall CPU usage of Squeak to be low. If self serverMode returns true then, always do a complete delay of 50ms, independant of my argument. This prevents the freezing problem described in Mantis #6581" | currentTime wait | self serverMode ifFalse: [ (lastCycleTime notNil and: [CanSurrenderToOS ~~ false]) ifTrue: [ currentTime := Time millisecondClockValue. wait := lastCycleTime + milliSecs - currentTime. (wait > 0 and: [ wait <= milliSecs ] ) ifTrue: [ (Delay forMilliseconds: wait) wait ] ] ] ifTrue: [ (Delay forMilliseconds: 50) wait ]. lastCycleTime := Time millisecondClockValue. CanSurrenderToOS := true. Well, you may want to tweak this a bit to get a feel on how things do work under Athens there. This is all generic Morphic in 1.4 so, you may be in for some differences with Athens. Isn't that big 50 millisecs hardcoded magic number nice :-( ? Maybe can there be a pref for that? Enjoy, Philippe Back 2012/9/5 S Krish <[hidden email]>: > > I understand the impact of rendering every millisecond.. > > > TestAnimationClock > #drawOn: aCanvas > > I have to dig in a bit more.. is the issue here.. not NB/ VGTigerDemo. > > Normally all of Morphic rendering is I presume , premised on the invocation > of this method recursively on all submorphs till all of them are rendered.. > for all morphs on screen. > > TestAnimationClockPanel: Also I have a similar override.. and it does not > give me any overhead.. though all it has is one Text.. string. > > Why should only Clock have such an overhead.. : is because of calculating > the hour/minute/hand vector .. ? > > Will dig in more and try to understand this for optimizations. > > > ********** > PS: I am not using the startStepping / stop.. mechanism as yet in these.. > > Maybe I am naive.. about presuming.. > > On Wed, Sep 5, 2012 at 3:36 AM, Igor Stasenko <[hidden email]> wrote: >> >> On 4 September 2012 16:18, S Krish <[hidden email]> >> wrote: >> > As an screenshot should explain it better.. >> > >> > This is now pushing the CPU to 66 - 90%+ almost all the time.. and as >> > the >> > top hogger of CPU constantly.. >> > >> hmm, what did you expected there? Cairo uses CPU for rendering. It is >> faster than balloon, must faster >> but sure thing if you run animation which renders new frame as soon as >> it finished previous one, >> it will consume full available CPU resources. >> >> >> > Not having VGTigerDemo does not alter it much.. so its not NativeBoost >> > at >> > fault per se.. >> > >> > Kill the clock and the VGTiger it comes down to a nice 4% CPU >> > >> >> >> >> >> > On Tue, Sep 4, 2012 at 7:08 PM, S Krish >> > <[hidden email]> >> > wrote: >> >> >> >> >> >> >> >> If we override #drawOn: and implement custom logic to draw.. every few >> >> milliseconds as it gets called the CPU usage shoots to available max.. >> >> >> >> Run four instances of the same class that overrides and does some >> >> moderately complex draw routine of say : CircleMorph with border set, >> >> few >> >> lines, color rendering.. >> >> >> >> I will send in the .st file later .. that can be tested against.. >> >> >> >> >> >> Is this expected or what are the ways to avoid this CPU overhead... >> >> >> >> >> >> NativeBoost animation, far more responsive.. also goes up very >> >> similarly. >> >> but little more tolerable... VGTigerMorph... more so than FlakesDemo... >> >> >> >> >> >> >> > >> >> >> >> -- >> Best regards, >> Igor Stasenko. >> > |
Re: Max CPU usage when #drawOn: is overridden
|
|
In reply to this post by S Krish
Also, check the implementors of stepTime.
e.g. in Balloon: BalloonMorph>>stepTime ^ 0 "every cycle" Ouch. Athens may have something similar. Philippe Back 2012/9/5 S Krish <[hidden email]>: > > I understand the impact of rendering every millisecond.. > > > TestAnimationClock > #drawOn: aCanvas > > I have to dig in a bit more.. is the issue here.. not NB/ VGTigerDemo. > > Normally all of Morphic rendering is I presume , premised on the invocation > of this method recursively on all submorphs till all of them are rendered.. > for all morphs on screen. > > TestAnimationClockPanel: Also I have a similar override.. and it does not > give me any overhead.. though all it has is one Text.. string. > > Why should only Clock have such an overhead.. : is because of calculating > the hour/minute/hand vector .. ? > > Will dig in more and try to understand this for optimizations. > > > ********** > PS: I am not using the startStepping / stop.. mechanism as yet in these.. > > Maybe I am naive.. about presuming.. > > On Wed, Sep 5, 2012 at 3:36 AM, Igor Stasenko <[hidden email]> wrote: >> >> On 4 September 2012 16:18, S Krish <[hidden email]> >> wrote: >> > As an screenshot should explain it better.. >> > >> > This is now pushing the CPU to 66 - 90%+ almost all the time.. and as >> > the >> > top hogger of CPU constantly.. >> > >> hmm, what did you expected there? Cairo uses CPU for rendering. It is >> faster than balloon, must faster >> but sure thing if you run animation which renders new frame as soon as >> it finished previous one, >> it will consume full available CPU resources. >> >> >> > Not having VGTigerDemo does not alter it much.. so its not NativeBoost >> > at >> > fault per se.. >> > >> > Kill the clock and the VGTiger it comes down to a nice 4% CPU >> > >> >> >> >> >> > On Tue, Sep 4, 2012 at 7:08 PM, S Krish >> > <[hidden email]> >> > wrote: >> >> >> >> >> >> >> >> If we override #drawOn: and implement custom logic to draw.. every few >> >> milliseconds as it gets called the CPU usage shoots to available max.. >> >> >> >> Run four instances of the same class that overrides and does some >> >> moderately complex draw routine of say : CircleMorph with border set, >> >> few >> >> lines, color rendering.. >> >> >> >> I will send in the .st file later .. that can be tested against.. >> >> >> >> >> >> Is this expected or what are the ways to avoid this CPU overhead... >> >> >> >> >> >> NativeBoost animation, far more responsive.. also goes up very >> >> similarly. >> >> but little more tolerable... VGTigerMorph... more so than FlakesDemo... >> >> >> >> >> >> >> > >> >> >> >> -- >> Best regards, >> Igor Stasenko. >> > |
|
|
Call it error / removable property rendering on drawOn: For: #stepTime ^5000. #drawOn: aCanvas
super drawOn: aCanvas. "Other draw routines: draw other submorphs, lines etc.. " self borderStyle: aStyleSetBasedOnTime . "This one statement makes it draw immediately.. for all morphs remove this it works like a charm rendering only every 5 seconds..stupid and obviously not a big need.. but in case needed.. better not placed here.."
Are there any other caveats is not known for now.. but its ok for now... On Wed, Sep 5, 2012 at 11:58 AM, [hidden email] <[hidden email]> wrote: Also, check the implementors of stepTime. |
|
|
Now with this one change:
You can do this on Athens rendering morphs or on the clock. #stepTime at 1000 ms it runs at about 6% CPU.. at 100 ms it runs up about 40%.. and for 20 ms.. that is more or less immediate rendering.. I see about 15 ms is consumed even if you set the stepTime to 1. the CPU usage peaks to 80%+...
On Wed, Sep 5, 2012 at 4:37 PM, S Krish <[hidden email]> wrote:
|
Re: Max CPU usage when #drawOn: is overridden
|
|
In reply to this post by philippeback
On 5 September 2012 08:25, [hidden email] <[hidden email]> wrote:
> Stepping methods are called in the main UI thread but they aren't > drawing anything. > > Then, what is the default cycle? > > Have a look at MorphicUIManager for answers, especially > spawnNewProcess, which basically does this: > > spawnNewProcess > > UIProcess := [ > [World doOneCycle. Processor yield. false] whileFalse: []. > ] newProcess priority: Processor userSchedulingPriority. > UIProcess resume > > World doOneCycle and the userSchedulingPriority are at play here. > > This will lead us to > > WorldState >> doOneCycleFor: aWorld > "Do one cycle of the interaction loop. This method is called > repeatedly when the world is running. This is a moderately private > method; a better alternative is usually either to wait for events or > to check the state of things from #step methods." > > self interCyclePause: MinCycleLapse. > self doOneCycleNowFor: aWorld. > > > And, yeah, here it is: > > WorldState >> interCyclePause: milliSecs > "delay enough that the previous cycle plus the amount of delay will > equal milliSecs. If the cycle is already expensive, then no delay > occurs. However, if the system is idly waiting for interaction from > the user, the method will delay for a proportionally long time and > cause the overall CPU usage of Squeak to be low. > If self serverMode returns true then, always do a complete delay of > 50ms, independant of my argument. This prevents the freezing problem > described in Mantis #6581" > > | currentTime wait | > self serverMode > ifFalse: [ > (lastCycleTime notNil and: [CanSurrenderToOS ~~ false]) ifTrue: [ > currentTime := Time millisecondClockValue. > wait := lastCycleTime + milliSecs - currentTime. > (wait > 0 and: [ wait <= milliSecs ] ) ifTrue: [ > (Delay forMilliseconds: wait) wait ] ] ] > ifTrue: [ (Delay forMilliseconds: 50) wait ]. > > lastCycleTime := Time millisecondClockValue. > CanSurrenderToOS := true. > > Well, you may want to tweak this a bit to get a feel on how things do > work under Athens there. > > This is all generic Morphic in 1.4 so, you may be in for some > differences with Athens. > Isn't that big 50 millisecs hardcoded magic number nice :-( ? > Maybe can there be a pref for that? > it is a default intercycle pause. actually you can set #stepTime to be 0 .. then this pause won't affect anything. If i not mistaken. If i do, then yes, it would be good to be able to dynamically change the pause depending on needs of world's morphs (i.e. #stepTime) > Enjoy, > > Philippe Back > > -- Best regards, Igor Stasenko. |
Re: Max CPU usage when #drawOn: is overridden
|
|
In reply to this post by S Krish
On 5 September 2012 13:07, S Krish <[hidden email]> wrote:
> Call it error / removable property rendering on drawOn: > > For: > > #stepTime > > ^5000. > > > #drawOn: aCanvas > > super drawOn: aCanvas. > > "Other draw routines: draw other submorphs, lines etc.. " > > self borderStyle: aStyleSetBasedOnTime . > because changing any visual properties of morph with add a damage rectangle to display, and that means that given morph will be constantly get redrawn, because it is always requests to be updated (since a visual property set).. > "This one statement makes it draw immediately.. for all morphs remove this > it works like a charm rendering only every 5 seconds..stupid and obviously > not a big need.. but in case needed.. better not placed here.." > > > Are there any other caveats is not known for now.. but its ok for now... > -- Best regards, Igor Stasenko. |
Re: Max CPU usage when #drawOn: is overridden
|
|
In reply to this post by Igor Stasenko
I would be surprised to see more than a WorldState instance for each World.
A World, the entire Smalltalk screen, is a PasteUpMorph.
Morphic-Worlds is the package that manages all this.
PateUpMorph>>runStepMethods worldState runStepMethodsIn: self WorldState>>doOneCycleNowFor: aWorld
"Immediately do one cycle of the interaction loop. This should not be called directly, but only via doOneCycleFor:"
DisplayScreen checkForNewScreenSize. "process user input events"
LastCycleTime := Time millisecondClockValue. self handsDo: [:h | ActiveHand := h.
h processEvents. ActiveHand := nil ].
"the default is the primary hand" ActiveHand := self hands first.
aWorld runStepMethods. "there are currently some variations here"
self displayWorldSafely: aWorld. Double dispatching crazyness aside, I doubt the pause affects anything like you say.
Philippe 2012/9/8 Igor Stasenko <[hidden email]> On 5 September 2012 08:25, [hidden email] <[hidden email]> wrote: |
«
Return to Pharo Smalltalk Users
|
1 view|%1 views
| Free forum by Nabble | Edit this page |