[squeak-dev] Re: The Trunk: Morphic-tfel.639.mcz

tim Rowledge tim at rowledge.org
Fri Feb 8 18:31:46 UTC 2013


On 08-02-2013, at 7:14 AM, Bob Arning <arning315 at comcast.net> 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; tim at rowledge.org; http://www.rowledge.org/tim
World Ends at Ten! Pictures at 11 on Fox News!




More information about the Squeak-dev mailing list