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.
>
>

Reply via email to