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 <krishnamachari.sudhakar@gmail.com>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, phil@highoctane.be <phil@highoctane.be>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 <krishnamachari.sudhakar@gmail.com>:
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 <siguctua@gmail.com> wrote:
On 4 September 2012 16:18, S Krish <krishnamachari.sudhakar@gmail.com> 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 <krishnamachari.sudhakar@gmail.com> 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.