Overhead of SystemProgressMorph/#do:displayingProgress: is huge

Am 06.10.2020 13:37:00 schrieb Thiede, Christoph <[hidden email]>:

[(1 to: 1000) do: [:i | 10 milliSeconds wait]] timeToRun. "--> 11758"

[(1 to: 1000) do: [:i | 10 milliSeconds wait] displayingProgress: [:x | x asString]] timeToRun. "--> 18528"

18528 / 11758. "--> 1.57"

In this example, in total, 3.9 seconds are spent in SystemProgressMorph(Morph) >> #updateDropShadowCache. I found out that in #setLayoutBoundsFromLayout:, the #dropShadow cache is cleared in every second iteration of the code from above! Why is bounds ~= outer? Is this a new layout problem? :-)

Best,

Christoph

Hi Marcel,

while doing a #do:displayingProgress: operation, nothing should be redrawn but the inner progress bar rectangle (and maybe the system clock), unless other morphs are changed at the same time, is this correct? In this case I do not understand why the dropShadow has to be recomputed within every draw cycle. Of 7.5 seconds in PasteUpMorph >> #displayWorld, my TimeProfileBrowser shows 5.3 seconds in #updateDropShadowCache.  Sorry for the ugly screenshot:

Apart from that, I think 10 fps would be enough, too, yes. Maybe we should reuse the selectionUpdateTime mechanism from Inspector if the displayDuring-aStringOrBlock block takes more time. :-)

Best,

Christoph

Am 06.10.2020 15:09:43 schrieb Thiede, Christoph <[hidden email]>:

Hi Marcel,

while doing a #do:displayingProgress: operation, nothing should be redrawn but the inner progress bar rectangle (and maybe the system clock), unless other morphs are changed at the same time, is this correct? In this case I do not understand why the dropShadow has to be recomputed within every draw cycle. Of 7.5 seconds in PasteUpMorph >> #displayWorld, my TimeProfileBrowser shows 5.3 seconds in #updateDropShadowCache.  Sorry for the ugly screenshot:

Apart from that, I think 10 fps would be enough, too, yes. Maybe we should reuse the selectionUpdateTime mechanism from Inspector if the displayDuring-aStringOrBlock block takes more time. :-)

Best,

Christoph

---

Von: Squeak-dev <[hidden email]> im Auftrag von Taeumel, Marcel
Gesendet: Dienstag, 6. Oktober 2020 14:32:17
An: squeak-dev
Betreff: Re: [squeak-dev] Overhead of SystemProgressMorph/#do:displayingProgress: is huge

 

> Is this a new layout problem? :-)

Showing visual progress is of course an overhead compared to not showing anything. The usual update rate is about 25 milliseconds? Hmmm... 11 vs. 18 seconds sounds reasonable given that you update the progress bar in this example about 400 times. This 7 second overhead amounts then to 17.5 milliseconds per update. Not good, right. Resizing my code browser from 500 to 1000 pixels in width takes about 4 milliseconds to re-layout -- but 36 milliseconds to re-layout and re-draw. Hmm....

We can improve those 17.5 milliseconds or increase the progress-bar update rate from 25 milliseconds to 200 milliseconds. :-)

Best,

Marcel

Am 06.10.2020 13:37:00 schrieb Thiede, Christoph <[hidden email]>:

[(1 to: 1000) do: [:i | 10 milliSeconds wait]] timeToRun. "--> 11758"

[(1 to: 1000) do: [:i | 10 milliSeconds wait] displayingProgress: [:x | x asString]] timeToRun. "--> 18528"

18528 / 11758. "--> 1.57"

In this example, in total, 3.9 seconds are spent in SystemProgressMorph(Morph) >> #updateDropShadowCache. I found out that in #setLayoutBoundsFromLayout:, the #dropShadow cache is cleared in every second iteration of the code from above! Why is bounds ~= outer? Is this a new layout problem? :-)

Best,

Christoph

Hi Marcel,

actually, the visible progress morph's extent seems not to change. However, during  the #extent: call, it is every time changed but after the layout is recomputed, the value is changed back. Unfortunately, at this time the dropShadow cache has already been cleared ...

Can we move that "self removeProperty: #dropShadow" statement from Morph >> #extent: to some deferred point, maybe #doLayoutIn:? Or add a second property, #dropShadowBounds, and invalidate the cache when looking it up only?

Best,

Christoph

Am 06.10.2020 16:36:05 schrieb Thiede, Christoph <[hidden email]>:

Hi Marcel,

actually, the visible progress morph's extent seems not to change. However, during  the #extent: call, it is every time changed but after the layout is recomputed, the value is changed back. Unfortunately, at this time the dropShadow cache has already been cleared ...

Can we move that "self removeProperty: #dropShadow" statement from Morph >> #extent: to some deferred point, maybe #doLayoutIn:? Or add a second property, #dropShadowBounds, and invalidate the cache when looking it up only?

Best,

Christoph

---

Von: Squeak-dev <[hidden email]> im Auftrag von Taeumel, Marcel
Gesendet: Dienstag, 6. Oktober 2020 15:11:44
An: squeak-dev
Betreff: Re: [squeak-dev] Overhead of SystemProgressMorph/#do:displayingProgress: is huge

 

Hmm... the progress morph's extent changes, thus the shadow is invalidated. Hmpf.

Best,

Marcel

Am 06.10.2020 15:09:43 schrieb Thiede, Christoph <[hidden email]>:

Hi Marcel,

while doing a #do:displayingProgress: operation, nothing should be redrawn but the inner progress bar rectangle (and maybe the system clock), unless other morphs are changed at the same time, is this correct? In this case I do not understand why the dropShadow has to be recomputed within every draw cycle. Of 7.5 seconds in PasteUpMorph >> #displayWorld, my TimeProfileBrowser shows 5.3 seconds in #updateDropShadowCache.  Sorry for the ugly screenshot:

Apart from that, I think 10 fps would be enough, too, yes. Maybe we should reuse the selectionUpdateTime mechanism from Inspector if the displayDuring-aStringOrBlock block takes more time. :-)

Best,

Christoph

---

Von: Squeak-dev <[hidden email]> im Auftrag von Taeumel, Marcel
Gesendet: Dienstag, 6. Oktober 2020 14:32:17
An: squeak-dev
Betreff: Re: [squeak-dev] Overhead of SystemProgressMorph/#do:displayingProgress: is huge

 

> Is this a new layout problem? :-)

Showing visual progress is of course an overhead compared to not showing anything. The usual update rate is about 25 milliseconds? Hmmm... 11 vs. 18 seconds sounds reasonable given that you update the progress bar in this example about 400 times. This 7 second overhead amounts then to 17.5 milliseconds per update. Not good, right. Resizing my code browser from 500 to 1000 pixels in width takes about 4 milliseconds to re-layout -- but 36 milliseconds to re-layout and re-draw. Hmm....

We can improve those 17.5 milliseconds or increase the progress-bar update rate from 25 milliseconds to 200 milliseconds. :-)

Best,

Marcel

Am 06.10.2020 13:37:00 schrieb Thiede, Christoph <[hidden email]>:

[(1 to: 1000) do: [:i | 10 milliSeconds wait]] timeToRun. "--> 11758"

[(1 to: 1000) do: [:i | 10 milliSeconds wait] displayingProgress: [:x | x asString]] timeToRun. "--> 18528"

18528 / 11758. "--> 1.57"

In this example, in total, 3.9 seconds are spent in SystemProgressMorph(Morph) >> #updateDropShadowCache. I found out that in #setLayoutBoundsFromLayout:, the #dropShadow cache is cleared in every second iteration of the code from above! Why is bounds ~= outer? Is this a new layout problem? :-)

Best,

Christoph