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, [email protected] <[email protected]>wrote: > 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 <[email protected]>: > > > > 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 <[email protected]> > wrote: > >> > >> On 4 September 2012 16:18, S Krish <[email protected]> > >> 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 > >> > <[email protected]> > >> > 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. > >> > > > >
