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
<[email protected]>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 *.
>
> * "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.
>> >>
>> >
>>
>>
>
