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
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@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
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
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@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@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
Hilaire do you want to see an animation? Stef On Wed, Apr 4, 2018 at 3:49 PM, Hilaire <hilaire@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
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
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
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
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
After some more investigation, I think it is not the greated bottleneck. When I render points not as discs but as Square, Athens is happy. I guess the Cairo way of doing this is very slow because its seems Cairo does not come with dedicated disc rendering code, it must be render with portion of arc, as far as I remember. If I prevent to render empty text label attached with each point, Athens is even happier. Text font rendering through Athens seems to be slow. Hilaire Le 04/04/2018 à 23:05, Hilaire a écrit :
It reduces by 50% the time to execution. Need to check if this trick #1 and #2 are still needed at P7 time.
-- Dr. Geo http://drgeo.eu
if I remember correctly that Cairo does not support arc and that igor was doing point interpolation to support it. stef On Thu, Apr 5, 2018 at 11:33 AM, Hilaire <hilaire@drgeo.eu> wrote:
After some more investigation, I think it is not the greated bottleneck.
When I render points not as discs but as Square, Athens is happy. I guess the Cairo way of doing this is very slow because its seems Cairo does not come with dedicated disc rendering code, it must be render with portion of arc, as far as I remember.
If I prevent to render empty text label attached with each point, Athens is even happier. Text font rendering through Athens seems to be slow.
Hilaire
Le 04/04/2018 à 23:05, Hilaire a écrit :
It reduces by 50% the time to execution. Need to check if this trick #1 and #2 are still needed at P7 time.
-- Dr. Geo http://drgeo.eu
HilaireFernandes wrote
After some more investigation, I think it is not the greated bottleneck.
When I render points not as discs but as Square, Athens is happy. I guess the Cairo way of doing this is very slow because its seems Cairo does not come with dedicated disc rendering code, it must be render with portion of arc, as far as I remember.
If I prevent to render empty text label attached with each point, Athens is even happier. Text font rendering through Athens seems to be slow.
Hilaire
Le 04/04/2018 à 23:05, Hilaire a écrit :
It reduces by 50% the time to execution. Need to check if this trick #1 and #2 are still needed at P7 time.
-- Dr. Geo http://drgeo.eu
My notes after looking at the profile for a short while, if anyone feels the urge to optimize; UFFI:
8.8% {11475ms} CairoFreetypeFontRenderer>>convertString:len:ofFont:toGlyphs:numGlyphs:x:y: | 4.7% {6098ms} ExternalAddress>>packToArity: | 4.5% {5789ms} ExternalAddress>>pointerAutoRelease | 2.6% {3439ms} ExternalAddress>>unpackFromArity:
The lifespan of arguments that need arity packing/unpacking is well known, rewriting to use explicit free should lessen the overhead somewhat. CAIRO:
26.6% {34593ms} CairoFreetypeFontRenderer>>glyphsOf:from:to: | 12.2% {15842ms} CairoGlyphsArray class>>new:
With this kind of overhead just to create the array to hold results, it might be worthwhile to use a buffer array (of sufficient size) for the primitive, and copyFrom:to: to return the actual glyphs... DRGEO:
20.9% {27116ms} DrGPointMorph>>drawOnAthensCanvas: |16.7% {21720ms} AthensCairoCanvas(AthensCanvas)>>createPath:
Storing the path in DrGPointMorph, rather than recreating for each draw:, should save alot of time.
7.7% {9962ms} DrGTextMorph>>drawOnAthensCanvas: | 7.7% {9962ms} Form>>asAthensPaintOn:
Same thing here, only storing the paint, rather than converting from form each draw. Cheers, Henry -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
On Thu, Apr 5, 2018, 16:09 Henrik Sperre Johansen < henrik.s.johansen@veloxit.no> wrote:
HilaireFernandes wrote
After some more investigation, I think it is not the greated bottleneck.
When I render points not as discs but as Square, Athens is happy. I guess the Cairo way of doing this is very slow because its seems Cairo does not come with dedicated disc rendering code, it must be render with portion of arc, as far as I remember.
If I prevent to render empty text label attached with each point, Athens is even happier. Text font rendering through Athens seems to be slow.
Hilaire
Le 04/04/2018 à 23:05, Hilaire a écrit :
It reduces by 50% the time to execution. Need to check if this trick #1 and #2 are still needed at P7 time.
-- Dr. Geo http://drgeo.eu
My notes after looking at the profile for a short while, if anyone feels the urge to optimize; UFFI:
8.8% {11475ms}
CairoFreetypeFontRenderer>>convertString:len:ofFont:toGlyphs:numGlyphs:x:y:
| 4.7% {6098ms} ExternalAddress>>packToArity: | 4.5% {5789ms} ExternalAddress>>pointerAutoRelease | 2.6% {3439ms} ExternalAddress>>unpackFromArity:
The lifespan of arguments that need arity packing/unpacking is well known, rewriting to use explicit free should lessen the overhead somewhat.
CAIRO:
26.6% {34593ms} CairoFreetypeFontRenderer>>glyphsOf:from:to: | 12.2% {15842ms} CairoGlyphsArray class>>new:
With this kind of overhead just to create the array to hold results, it might be worthwhile to use a buffer array (of sufficient size) for the primitive, and copyFrom:to: to return the actual glyphs...
DRGEO:
20.9% {27116ms} DrGPointMorph>>drawOnAthensCanvas: |16.7% {21720ms} AthensCairoCanvas(AthensCanvas)>>createPath:
Storing the path in DrGPointMorph, rather than recreating for each draw:, should save alot of time.
7.7% {9962ms} DrGTextMorph>>drawOnAthensCanvas: | 7.7% {9962ms} Form>>asAthensPaintOn:
Same thing here, only storing the paint, rather than converting from form each draw.
This would also be beneficial to Roassal when zooming in and out of vusualization with a ton of labels. Phil
Cheers, Henry
-- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
Le 05/04/2018 à 16:09, Henrik Sperre Johansen a écrit :
DRGEO:
20.9% {27116ms} DrGPointMorph>>drawOnAthensCanvas: |16.7% {21720ms} AthensCairoCanvas(AthensCanvas)>>createPath: Storing the path in DrGPointMorph, rather than recreating for each draw:, should save alot of time.
Indeed should work nicely for point with round shape. For rectangle shape it is not necessary, this what I did in the demo.
7.7% {9962ms} DrGTextMorph>>drawOnAthensCanvas: | 7.7% {9962ms} Form>>asAthensPaintOn: Same thing here, only storing the paint, rather than converting from form each draw. In my demo, the text changes at each iteration. Useful for static geometric item label thought. But I already optimized this by discarding empty label
The cache suggestions will be find for static surface, it does not apply always though. In the scenario where Dr.Geo is used for animated demonstration, I already found a few optimization for Dr.Geo itself without touching to the Athens layer. Thanks for your review Hilaire -- Dr. Geo http://drgeo.eu
Thanks for your analysis. Should we open a enhancement issue for UFFI? Stf On Thu, Apr 5, 2018 at 4:09 PM, Henrik Sperre Johansen <henrik.s.johansen@veloxit.no> wrote:
HilaireFernandes wrote
After some more investigation, I think it is not the greated bottleneck.
When I render points not as discs but as Square, Athens is happy. I guess the Cairo way of doing this is very slow because its seems Cairo does not come with dedicated disc rendering code, it must be render with portion of arc, as far as I remember.
If I prevent to render empty text label attached with each point, Athens is even happier. Text font rendering through Athens seems to be slow.
Hilaire
Le 04/04/2018 à 23:05, Hilaire a écrit :
It reduces by 50% the time to execution. Need to check if this trick #1 and #2 are still needed at P7 time.
-- Dr. Geo http://drgeo.eu
My notes after looking at the profile for a short while, if anyone feels the urge to optimize; UFFI:
8.8% {11475ms} CairoFreetypeFontRenderer>>convertString:len:ofFont:toGlyphs:numGlyphs:x:y: | 4.7% {6098ms} ExternalAddress>>packToArity: | 4.5% {5789ms} ExternalAddress>>pointerAutoRelease | 2.6% {3439ms} ExternalAddress>>unpackFromArity:
The lifespan of arguments that need arity packing/unpacking is well known, rewriting to use explicit free should lessen the overhead somewhat.
CAIRO:
26.6% {34593ms} CairoFreetypeFontRenderer>>glyphsOf:from:to: | 12.2% {15842ms} CairoGlyphsArray class>>new:
With this kind of overhead just to create the array to hold results, it might be worthwhile to use a buffer array (of sufficient size) for the primitive, and copyFrom:to: to return the actual glyphs...
DRGEO:
20.9% {27116ms} DrGPointMorph>>drawOnAthensCanvas: |16.7% {21720ms} AthensCairoCanvas(AthensCanvas)>>createPath:
Storing the path in DrGPointMorph, rather than recreating for each draw:, should save alot of time.
7.7% {9962ms} DrGTextMorph>>drawOnAthensCanvas: | 7.7% {9962ms} Form>>asAthensPaintOn:
Same thing here, only storing the paint, rather than converting from form each draw.
Cheers, Henry
-- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
participants (6)
-
Clément Bera -
Henrik Sperre Johansen -
Hilaire -
phil＠highoctane.be -
Stephane Ducasse -
Thierry Goubier