- Pharo-users - lists.pharo.org

Re: [Pharo-users] Pharo 2.0 + Seaside

by Dale Henrichs

The configuration for Seaside3.1 exposed a bug in Metacello ... I have a fix for the bug in place, but I have one or two additional bugs/features to implement[1] that are also related to the Seaside3.1 configuration needs ... Dale [1] https://github.com/dalehenrich/metacello-work/issues?milestone=4&page=1&sor… ----- Original Message ----- | From: "Mariano Martinez Peck" <marianopeck(a)gmail.com> | To: "A friendly place where any question about pharo is welcome" <pharo-users(a)lists.gforge.inria.fr> | Sent: Friday, September 7, 2012 3:22:26 AM | Subject: Re: [Pharo-users] Pharo 2.0 + Seaside | | | | | On Sun, Aug 26, 2012 at 1:52 PM, Chris < cpmbailey(a)btinternet.com > | wrote: | | | | | On 24/08/2012 14:09, StÃ©phane Ducasse wrote: | | | On Aug 24, 2012, at 2:28 PM, Chris wrote: | | | | I would love to start using Pharo 2.0 but really need Seaside to be | working. I'm assuming from what I've read that it is possible, but | got some issues such as BlockContext missing, references to | OmniBrowser, something about loading Metacello and when it finished | there were 39 failures/errors in the tests. This was just from | loading from the configuration browser in a fresh 2.0 image. Is | there a better way? I like the look of the new system browser so far | but it has felt a little sluggish in places. I hope this improves as | I almost don't want to go back to OmniBrowser now :-) | :) | | Chris | | Do not start with 2.0 because we are shaking the system :) | Now imagine that you really want, then start from the seaside | configurationOfSeaside and let us know the problem you find. | | I'm quite happy with1.4 currently but would like to try things such | as Fuel, Tanker, Nautilus and so on. | | | Fuel works from Pharo 1.1 to Pharo 2.o. Tanker will only work in 2.0. | Seaside is working in 2.0 but not yet the ConfigurationOf. During | ESUG Seasiders said it was going to be fixed soon. | | | With regards to Seaside, it's actually pretty close to be fair. I had | to prefix MetacelloMCProject with Smalltalk at: in | ConfigurationOfMetacello>># project. The OmniBrowser packages | obviously complained but I just proceeded. There are methods such as | fixCallbackTemps on BlockContext and that class is now gone, | presumably these could move to ContextPart? Of the failing tests | after that, most were just a case of renaming calls to | includesSubString: with includesSubstring: . Most of the other | errors were related to SystemChangeNotifier no longer existing, the | odd one where FileDirectory doesn't and so on | | | | | | | | | | | | -- | Mariano | http://marianopeck.wordpress.com | |

Sept. 7, 2012

Re: [Pharo-users] Pharo 2.0 + Seaside

by Mariano Martinez Peck

On Sun, Aug 26, 2012 at 1:52 PM, Chris <cpmbailey(a)btinternet.com> wrote: > On 24/08/2012 14:09, StÃ©phane Ducasse wrote: > >> On Aug 24, 2012, at 2:28 PM, Chris wrote: >> >> I would love to start using Pharo 2.0 but really need Seaside to be >>> working. I'm assuming from what I've read that it is possible, but got some >>> issues such as BlockContext missing, references to OmniBrowser, something >>> about loading Metacello and when it finished there were 39 failures/errors >>> in the tests. This was just from loading from the configuration browser in >>> a fresh 2.0 image. Is there a better way? I like the look of the new system >>> browser so far but it has felt a little sluggish in places. I hope this >>> improves as I almost don't want to go back to OmniBrowser now :-) >>> >> :) >> >> Chris >> >> Do not start with 2.0 because we are shaking the system :) >> Now imagine that you really want, then start from the seaside >> configurationOfSeaside and let us know the problem you find. >> > > I'm quite happy with1.4 currently but would like to try things such as > Fuel, Tanker, Nautilus and so on. Fuel works from Pharo 1.1 to Pharo 2.o. Tanker will only work in 2.0. Seaside is working in 2.0 but not yet the ConfigurationOf. During ESUG Seasiders said it was going to be fixed soon. > With regards to Seaside, it's actually pretty close to be fair. I had to > prefix MetacelloMCProject with Smalltalk at: in ConfigurationOfMetacello>># > **project. The OmniBrowser packages obviously complained but I just > proceeded. There are methods such as fixCallbackTemps on BlockContext and > that class is now gone, presumably these could move to ContextPart? Of the > failing tests after that, most were just a case of renaming calls to > includesSubString: with includesSubstring: . Most of the other errors were > related to SystemChangeNotifier no longer existing, the odd one where > FileDirectory doesn't and so on > >> >> >> >> > > -- Mariano http://marianopeck.wordpress.com

Sept. 7, 2012

ss3.gemstone.com MAINTENANCE Friday September 7 from 2pm-3pm PDT

by Dale Henrichs

ss3.gemstone.com will be down for Maintenance this Friday (September 7) for 1 hour starting at 2pm PDT. We're fixing a configuration issue (my mistake:). Dale

Sept. 5, 2012

Re: [Pharo-users] [Pharo-project] Zinc-HTTP-Deprecated

by Sven Van Caekenberghe

FYI, Sven Van Caekenberghe uploaded a new version of Zinc-HTTP to project Zinc HTTP Components: http://www.squeaksource.com/ZincHTTPComponents/Zinc-HTTP-SvenVanCaekenbergh… ==================== Summary ==================== Name: Zinc-HTTP-SvenVanCaekenberghe.300 Author: SvenVanCaekenberghe Time: 5 September 2012, 1:59:02 am UUID: a09fb75e-0ba5-489c-bc1b-435481a08164 Ancestors: Zinc-HTTP-SvenVanCaekenberghe.299 removal of all classes in Zinc-HTTP-Deprecated - ZnClientOld - ZnFixedClient - ZnExtendedFixedClient - ZnUserAgent - ZnHttpClient - ZnUserAgentSettings as well as all their unit test classes On 23 Aug 2012, at 15:52, Sven Van Caekenberghe <sven(a)beta9.be> wrote: > There is a class category called 'Zinc-HTTP-Deprecated'. It contains some old classes that were replaced/superceded by newer ones almost a year ago. > > I plan to actually delete these and their unit tests in a commit in the next couple of days. > > Specifically, the following classes will be removed: > > - ZnClientOld > - ZnFixedClient > - ZnExtendedFixedClient > - ZnUserAgent > - ZnHttpClient > - ZnUserAgentSettings > > I hope nobody uses these anymore. > > > Sven > > > -- > Sven Van Caekenberghe > http://stfx.eu > Smalltalk is the Red Pill

Sept. 5, 2012

Re: [Pharo-users] Max CPU usage when #drawOn: is overridden

by S Krish

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

Sept. 5, 2012

Re: [Pharo-users] Max CPU usage when #drawOn: is overridden

by S Krish

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

Sept. 5, 2012

Re: [Pharo-users] Get the point of Intersection for Morphs

by Camillo Bruni

On 2012-09-05, at 01:22, irfankhan1 <irfankhan(a)hotmail.ca> wrote: > I have a new class for Circle Morph which has a step method that increases > the diameter. > > > step > > self extent: self extent +1. > (self extent )>(400@400) ifTrue: [self stopStepping] > > > b:=CircleAnimeMorph new // new class for Circle Morph > b openInWorld > b startStepping > b1:CircleAnimeMorph new > b1 openInWorld > b1 startStepping. > > > > > So when these both Circles meet i wanna get the Intersecting point,idk how > to implement this can any one help? see all the details here: http://mathworld.wolfram.com/Circle-CircleIntersection.html basically you first check if both radii overlap, once you know that you can do the detailed trigonometry to get the intersection points. As a first step I would implement a #intersectsCircle: aCircle method. The I think it makes most sense to put the two circles into a surrounding morph which will take care of the intersection check. Simply override the step method there and perform the tests.

Sept. 5, 2012

Re: [Pharo-users] Max CPU usage when #drawOn: is overridden

by phil＠highoctane.be

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(a)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(a)gmail.com> wrote: >> >> On 4 September 2012 16:18, S Krish <krishnamachari.sudhakar(a)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(a)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. >> >

Sept. 5, 2012

Re: [Pharo-users] Max CPU usage when #drawOn: is overridden

by phil＠highoctane.be

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 <krishnamachari.sudhakar(a)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(a)gmail.com> wrote: >> >> On 4 September 2012 16:18, S Krish <krishnamachari.sudhakar(a)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(a)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. >> >

Sept. 5, 2012

Re: [Pharo-users] Max CPU usage when #drawOn: is overridden

by S Krish

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(a)gmail.com> wrote: > On 4 September 2012 16:18, S Krish <krishnamachari.sudhakar(a)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(a)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. > >

Sept. 5, 2012