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

Reply via email to