- Pharo-users - lists.pharo.org

Re: [Pharo-users] Slower

by Hilaire

Looking at the profile, Athens spend time on some of my widgets: 1. LabelMorph with a workaround in the draw method as: drawOnAthensCanvas: aCanvas "Work around for the conflicting size font problem" Â Â Â aCanvas pathTransform restoreAfter: [ Â Â Â aCanvas pathTransform scaleBy: 1.00001. Â Â Â Â Â Â "draw text here" Â Â Â Â Â Â super drawOnAthensCanvas: aCanvas]. Do we still need to do that, may be not. 2. TextMorph with another workaround: drawOnAthensCanvas: aCanvas Â Â Â | cached | Â Â Â myForm ifNil: [myForm := self imageForm]. Â Â Â cached := aCanvas cacheAt: myForm ifAbsentPut: [ Â Â Â Â Â Â myForm asAthensPaintOn: aCanvas.Â Â Â ]. Â Â Â aCanvas setPaint: cached. Â Â Â aCanvas paintTransform restoreAfter: [ Â Â Â Â Â Â aCanvas paintTransform translateBy: self fullBounds origin truncated. Â Â Â Â Â Â aCanvas drawShape: self fullBounds]. It should be faster but it is slower. 3. PointMorph, painting as round shape is slow, painting point as square is way faster. It reduces by 50% the time to execution. Need to check if this trick #1 and #2 are still needed at P7 time. Hilaire Le 04/04/2018 Ã 22:31, Hilaire a Ã©critÂ : > From the profile, there are a lot of activities with Athens. I can't > say if it is normal... Someone with good knowledge could dig on it. I > can provide the environment to test. -- Dr. Geo http://drgeo.eu

April 4, 2018

Re: [Pharo-users] Slower

by Hilaire

You mean one iteration? Hilaire Le 04/04/2018 Ã 20:05, Thierry Goubier a Ã©critÂ : > > Can you profile a refresh / a redraw? > > We've seen many times Morphic being qualified as slow, and the culprit > were very badly programmed widgets. > > Thierry -- Dr. Geo http://drgeo.eu

April 4, 2018

Re: [Pharo-users] To be there or not to be there

by Sean P. DeNigris

HilaireFernandes wrote > I come to a situation where methods seems to be there without been > there. I encountered two seemingly similar problems, not sure yet how to reproduce and also may have been fixed since then, but for reference they were: - extension methods saved 2 places in filetree - both in the correct package and the package of the extended class - extension methods which are clearly there, but don't show up in Iceberg. IIRC I had to move the method from a package tag up one level to the package (i.g. from 'Package-Tag' to 'Package') ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

April 4, 2018

Re: [Pharo-users] Slower

by Thierry Goubier

Le 04/04/2018 Ã 19:31, Hilaire a Ã©critÂ : > It is already animated :) > https://twitter.com/GNUDrGeo/status/981583820037160961 > > But canvas get slow when I push to 500 montecarlo iterations, for example. Can you profile a refresh / a redraw? We've seen many times Morphic being qualified as slow, and the culprit were very badly programmed widgets. Thierry > > Le 04/04/2018 Ã 19:03, Stephane Ducasse a Ã©critÂ : >> Hilaire >> >> do you want to see an animation? >> >> Stef >

April 4, 2018

Re: [Pharo-users] Slower

by Hilaire

It is already animated :) https://twitter.com/GNUDrGeo/status/981583820037160961 But canvas get slow when I push to 500 montecarlo iterations, for example. Le 04/04/2018 Ã 19:03, Stephane Ducasse a Ã©critÂ : > Hilaire > > do you want to see an animation? > > Stef -- Dr. Geo http://drgeo.eu

April 4, 2018

Re: [Pharo-users] Slower

by Stephane Ducasse

Hilaire do you want to see an animation? Stef On Wed, Apr 4, 2018 at 3:49 PM, Hilaire <hilaire(a)drgeo.eu> wrote: > Hi, > > I discover this Dr. Geo Smalltalk sketch to animate is about 60% slowler on > P7 compare to P3: > > | fig point comment x y random inArc tries| > "Monte-Carlo PI approximation" > fig := DrGeoCanvas new fullscreen scale: 400. > fig arcCenter: 0@0 from: 1@0 to: 0@1. > fig polygon: { 0@0. 0@1. 1@1. 1@0 }. > comment := fig texte: '' a: 0@ -0.1. > random := Random seed: Time millisecondClockValue. > tries := 500. > inArc := 0. > [1 a: tries faire: [: try | > x := random next. > y := random next. > point := (fig point: x@y) small. > (x squared + y squared) > 1 > ifTrue: [point color: Color blue ] > ifFalse: [inArc := inArc + 1 ]. > comment text: 'Tries: ', try asString, ' > approx: ', (inArc * 4 / try) asFloat asString. > World doOneCycle. > ] ] timeProfile > > The log are enclosed to compare. The mains differences seems to be during > the world update. Years ago when porting to P3 I also see an important time > performance degradation[1] and it remained unresolved. > > > [1] http://forum.world.st/Slowness-question-tt4761717.html > > > > > -- > Dr. Geo > http://drgeo.eu >

April 4, 2018

Re: [Pharo-users] Slower

by Stephane Ducasse

Clement if it would be nice to have the fastCorner and friends added to rectangle. On Wed, Apr 4, 2018 at 5:33 PM, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > Hi Hilaire, > > Do you have to use the world or Morphic at all ? > > I wrote 2 different real-time 2D games at 50fps in Pharo [1,2]. I tried > using Morphic but that was crazy slow I could not even get 20fps. Instead I > use direct bindings to Cairo surface and SDL2 window and I don't open the > world morph at all to avoid the delays due to its cycles which are also > crazy (I open Pharo in headless, then the Pharo code opens a SDL2 window and > draws on it using Cairo). Then I was just careful on the number of > allocations, especially closures, in between frame rendering and also on > algorithms (I had 60% of time spent creating rectangle in corner: since it > performs a lot of min max computation, rewriting that to fastCorner method > without min max greatly improved the performance in my case). I still have > frame drops from time to time but that's hardly noticeable. > > If you're scared of using Cairo / SDL2 because you deploy on specific > platforms like mobiles, you can still use BitBlt. The point being not to run > WorldMorph cycles at all but instead manage yourself what is drawn. If > possible don't use Morph at all too, it has many features that likely you > don't use, slowing down your system and wasting battery on mobiles for > nothing. > > [1] https://github.com/clementbera/wizard-battle-arena > [2] https://github.com/clementbera/SpiderInvasion > > > On Wed, Apr 4, 2018, 15:49 Hilaire <hilaire(a)drgeo.eu> wrote: >> >> Hi, >> >> I discover this Dr. Geo Smalltalk sketch to animate is about 60% slowler >> on P7 compare to P3: >> >> | fig point comment x y random inArc tries| >> "Monte-Carlo PI approximation" >> fig := DrGeoCanvas new fullscreen scale: 400. >> fig arcCenter: 0@0 from: 1@0 to: 0@1. >> fig polygon: { 0@0. 0@1. 1@1. 1@0 }. >> comment := fig texte: '' a: 0@ -0.1. >> random := Random seed: Time millisecondClockValue. >> tries := 500. >> inArc := 0. >> [1 a: tries faire: [: try | >> x := random next. >> y := random next. >> point := (fig point: x@y) small. >> (x squared + y squared) > 1 >> ifTrue: [point color: Color blue ] >> ifFalse: [inArc := inArc + 1 ]. >> comment text: 'Tries: ', try asString, ' >> approx: ', (inArc * 4 / try) asFloat asString. >> World doOneCycle. >> ] ] timeProfile >> >> The log are enclosed to compare. The mains differences seems to be >> during the world update. Years ago when porting to P3 I also see an >> important time performance degradation[1] and it remained unresolved. >> >> >> [1] http://forum.world.st/Slowness-question-tt4761717.html >> >> >> >> >> -- >> Dr. Geo >> http://drgeo.eu >> >

April 4, 2018

Re: [Pharo-users] Slower

by Hilaire

Hi Clement, I know about your SDL games demo. But DrGeo is really Morphic based, so yes it is mandatory. I suspect there is may be something going on between Cairo/Athens/Morph. For regular mouse use of DrGeo it is just fine. It is when pusing to the limite with Smalltalk sketch and animating the resulting sktech. Le 04/04/2018 Ã 17:33, ClÃ©ment Bera a Ã©critÂ : > Hi Hilaire, > > Do you have to use the world or Morphic at all ? > -- Dr. Geo http://drgeo.eu

April 4, 2018

Re: [Pharo-users] Slower

by ClÃ©ment Bera

Hi Hilaire, Do you have to use the world or Morphic at all ? I wrote 2 different real-time 2D games at 50fps in Pharo [1,2]. I tried using Morphic but that was crazy slow I could not even get 20fps. Instead I use direct bindings to Cairo surface and SDL2 window and I don't open the world morph at all to avoid the delays due to its cycles which are also crazy (I open Pharo in headless, then the Pharo code opens a SDL2 window and draws on it using Cairo). Then I was just careful on the number of allocations, especially closures, in between frame rendering and also on algorithms (I had 60% of time spent creating rectangle in corner: since it performs a lot of min max computation, rewriting that to fastCorner method without min max greatly improved the performance in my case). I still have frame drops from time to time but that's hardly noticeable. If you're scared of using Cairo / SDL2 because you deploy on specific platforms like mobiles, you can still use BitBlt. The point being not to run WorldMorph cycles at all but instead manage yourself what is drawn. If possible don't use Morph at all too, it has many features that likely you don't use, slowing down your system and wasting battery on mobiles for nothing. [1] https://github.com/clementbera/wizard-battle-arena [2] https://github.com/clementbera/SpiderInvasion On Wed, Apr 4, 2018, 15:49 Hilaire <hilaire(a)drgeo.eu> wrote: > Hi, > > I discover this Dr. Geo Smalltalk sketch to animate is about 60% slowler > on P7 compare to P3: > > | fig point comment x y random inArc tries| > "Monte-Carlo PI approximation" > fig := DrGeoCanvas new fullscreen scale: 400. > fig arcCenter: 0@0 from: 1@0 to: 0@1. > fig polygon: { 0@0. 0@1. 1@1. 1@0 }. > comment := fig texte: '' a: 0@ -0.1. > random := Random seed: Time millisecondClockValue. > tries := 500. > inArc := 0. > [1 a: tries faire: [: try | > x := random next. > y := random next. > point := (fig point: x@y) small. > (x squared + y squared) > 1 > ifTrue: [point color: Color blue ] > ifFalse: [inArc := inArc + 1 ]. > comment text: 'Tries: ', try asString, ' > approx: ', (inArc * 4 / try) asFloat asString. > World doOneCycle. > ] ] timeProfile > > The log are enclosed to compare. The mains differences seems to be > during the world update. Years ago when porting to P3 I also see an > important time performance degradation[1] and it remained unresolved. > > > [1] http://forum.world.st/Slowness-question-tt4761717.html > > > > > -- > Dr. Geo > http://drgeo.eu > >

April 4, 2018

Slower

by Hilaire

Hi, I discover this Dr. Geo Smalltalk sketch to animate is about 60% slowler on P7 compare to P3: | fig point comment x y random inArc tries| "Monte-Carlo PI approximation" fig := DrGeoCanvas new fullscreen scale: 400. fig arcCenter: 0@0 from:Â 1@0 to: 0@1. fig polygon: { 0@0. 0@1. 1@1. 1@0 }. comment := fig texte: '' a: 0@ -0.1. random := Random seed: Time millisecondClockValue. tries := 500. inArc := 0. [1 a: tries faire: [: try | Â Â Â x := random next. Â Â Â y := random next. Â Â Â point := (fig point: x@y) small. Â Â Â (x squared + y squared) > 1 Â Â Â Â Â Â ifTrue: [point color: Color blueÂ ] Â Â Â Â Â Â ifFalse: [inArc := inArc + 1 ]. comment text: 'Tries: ', try asString, ' approx: ', (inArc * 4 / try) asFloat asString. World doOneCycle. ] ] timeProfile The log are enclosed to compare. The mains differences seems to be during the world update. Years ago when porting to P3 I also see an important time performance degradation[1] and it remained unresolved. [1] http://forum.world.st/Slowness-question-tt4761717.html -- Dr. Geo http://drgeo.eu

April 4, 2018