Tim Felgentreff uploaded a new version of Morphic to project The Trunk:
http://source.squeak.org/trunk/Morphic-tfel.639.mcz ==================== Summary ==================== Name: Morphic-tfel.639 Author: ms Time: 8 February 2013, 1:43:38.624 pm UUID: bebde0c0-6b14-4410-83a6-94aab186c524 Ancestors: Morphic-fbs.638 Avoid redrawing the main docking bar all the time. This is a huge resource hog if you reach the threshold in the DamageRecorder and the docking bar damage rectangle is merged with the others, effectively forcing a huge chunk of the World redrawn =============== Diff against Morphic-fbs.638 =============== Item was added: + (PackageInfo named: 'Morphic') postscriptOfRemoval: 'nil'! Item was added: + (PackageInfo named: 'Morphic') preamble: 'nil'! Item was changed: ----- Method: DockingBarMorph>>extent: (in category 'geometry') ----- extent: aPoint "change the receiver's extent" + (bounds extent closeTo: aPoint) ifTrue: [^ self]. super extent: aPoint. self updateColor! |
Maybe we could also remove the seconds from the clock (by default) and/or raise the limit-before-merge of the DamageRecorder a little bit? Maybe from 15 to 500? Why is it exactly 15 anyway?
Best, Marcel |
15 is an empirical number from a long time ago.
More rectangles can increase the number of times a given morph may
be asked to draw in a single update cycle. Fewer rectangles
increases the chances for a morph to be included when it
hasn't changed itself. It's easy enough to change the 15 and to
limit the clock display. It's also pretty easy to capture some data
in PasteUpMorph>>privateOuterDisplayWorld to see what the
effects are. Might be a big win or something less amazing.
Cheers, Bob On 2/8/13 9:56 AM, Marcel Taeumel
wrote:
Maybe we could also remove the seconds from the clock (by default) and/or raise the limit-before-merge of the DamageRecorder a little bit? Maybe from 15 to 500? Why is it exactly 15 anyway? Best, Marcel -- View this message in context: http://forum.world.st/The-Trunk-Morphic-tfel-639-mcz-tp4668514p4668610.html Sent from the Squeak - Dev mailing list archive at Nabble.com. |
On 08-02-2013, at 7:14 AM, Bob Arning <[hidden email]> wrote: > 15 is an empirical number from a long time ago. More rectangles can increase the number of times a given morph may be asked to draw in a single update cycle. Fewer rectangles increases the chances for a morph to be included when it hasn't changed itself. It's easy enough to change the 15 and to limit the clock display. It's also pretty easy to capture some data in PasteUpMorph>>privateOuterDisplayWorld to see what the effects are. Might be a big win or something less amazing. A plea here for letting the platform related code - ie the VM right now, but damn well ought to be some platform bridges and policies in the image - deal with assorted cost/benefits of number vs. size of things like bitblts to the actual screen. On some machines it makes sense to do every little display-to-screen right now because maybe there is a really fast GPU doohickey and it costs no time at all. On others it might make sense to merge several tiny but widely spread regions into a single big one because the memory bandwidth is good but the setup time is horrendous. There's way too much code buried in the system that tries to work for all machines and all cases, often with no explanation why certain strategies or values were used or what they mean, let alone how changing things might work. There are poorly explained image workarounds for vm problems, sometimes for only one platform or even OS level. That leads to counter-work-arounds getting embedded in the VM, with no good explanation for what is going on. Looking into the sound system recently in order to get it going on the RISC OS Pi was a horrible reminder of just how appalling some of this can get. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim World Ends at Ten! Pictures at 11 on Fox News! |
Quoting tim Rowledge <[hidden email]>:
> > On 08-02-2013, at 7:14 AM, Bob Arning <[hidden email]> wrote: > >> 15 is an empirical number from a long time ago. More rectangles can >> increase the number of times a given morph may be asked to draw in >> a single update cycle. Fewer rectangles increases the chances for a >> morph to be included when it hasn't changed itself. It's easy >> enough to change the 15 and to limit the clock display. It's also >> pretty easy to capture some data in >> PasteUpMorph>>privateOuterDisplayWorld to see what the effects are. >> Might be a big win or something less amazing. > > A plea here for letting the platform related code - ie the VM right > now, but damn well ought to be some platform bridges and policies in > the image - deal with assorted cost/benefits of number vs. size of > things like bitblts to the actual screen. > > On some machines it makes sense to do every little display-to-screen > right now because maybe there is a really fast GPU doohickey and it > costs no time at all. On others it might make sense to merge several > tiny but widely spread regions into a single big one because the > memory bandwidth is good but the setup time is horrendous. > > There's way too much code buried in the system that tries to work > for all machines and all cases, often with no explanation why > certain strategies or values were used or what they mean, let alone > how changing things might work. There are poorly explained image > workarounds for vm problems, sometimes for only one platform or even > OS level. That leads to counter-work-arounds getting embedded in the > VM, with no good explanation for what is going on. Looking into the > sound system recently in order to get it going on the RISC OS Pi was > a horrible reminder of just how appalling some of this can get. > > > tim > -- > tim Rowledge; [hidden email]; http://www.rowledge.org/tim > World Ends at Ten! Pictures at 11 on Fox News! > > > > I fully agree with you. In any case, in Cuis I redid the rectangle merge and update logic, and the result is much faster display redraws when there are many overlapping windows. Cheers, Juan Vuletich |
In reply to this post by marcel.taeumel (old)
I use the seconds indicator on the clock all the time. Please do not
remove it. If THAT little thing is a resource hog then there's a bigger problem that needs fixed than removing that.. :) On Fri, Feb 8, 2013 at 8:56 AM, Marcel Taeumel <[hidden email]> wrote: > Maybe we could also remove the seconds from the clock (by default) and/or > raise the limit-before-merge of the DamageRecorder a little bit? Maybe from > 15 to 500? Why is it exactly 15 anyway? > > Best, > Marcel > > > > -- > View this message in context: http://forum.world.st/The-Trunk-Morphic-tfel-639-mcz-tp4668514p4668610.html > Sent from the Squeak - Dev mailing list archive at Nabble.com. > |
In reply to this post by marcel.taeumel (old)
https://dl.dropbox.com/u/28914094/ScreenUpdating.6.cs.gz
has some code for seeing the effect of changing the max number of damage rectangles. Cheers, Bob On 2/8/13 9:56 AM, Marcel Taeumel
wrote:
Maybe we could also remove the seconds from the clock (by default) and/or raise the limit-before-merge of the DamageRecorder a little bit? Maybe from 15 to 500? Why is it exactly 15 anyway? Best, Marcel -- View this message in context: http://forum.world.st/The-Trunk-Morphic-tfel-639-mcz-tp4668514p4668610.html Sent from the Squeak - Dev mailing list archive at Nabble.com. |
In reply to this post by commits-2
On 2013-02-08, at 12:43, [hidden email] wrote:
> Tim Felgentreff uploaded a new version of Morphic to project The Trunk: > http://source.squeak.org/trunk/Morphic-tfel.639.mcz > > Item was added: > + (PackageInfo named: 'Morphic') postscriptOfRemoval: 'nil'! > > Item was added: > + (PackageInfo named: 'Morphic') preamble: 'nil'! Are you using a different Monticello version? These should not appear when saving anymore ... or maybe your package info is in a funky state where it actually has the string 'nil' as scripts? - Bert - |
Free forum by Nabble | Edit this page |