[squeak-dev] Overhead of SystemProgressMorph/#do:displayingProgress: is huge

Marcel Taeumel marcel.taeumel at hpi.de
Tue Oct 6 14:39:44 UTC 2020


Hi Christoph,

try to get rid of that extra send of #extent: with bogus values.

> 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?

Doesn't sound like a good idea. I would focus on that extra send of #extent: that has strange values.

Best,
Marcel
Am 06.10.2020 16:36:05 schrieb Thiede, Christoph <christoph.thiede at student.hpi.uni-potsdam.de>:
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
[http://www.hpi.de/]
Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> 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 <christoph.thiede at student.hpi.uni-potsdam.de>:
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
[http://www.hpi.de/]
Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> 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 <christoph.thiede at student.hpi.uni-potsdam.de>:
[(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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20201006/dbe09e6e/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pastedImage.png
Type: image/png
Size: 373109 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20201006/dbe09e6e/attachment-0001.png>


More information about the Squeak-dev mailing list