and if you don't want to run animation, do not use #startStepping method. On 5 September 2012 00:06, 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.
-- Best regards, Igor Stasenko.
