[Vm-dev] Primitive 126 | Its problems and its future :-)

Craig Latta craig at blackpagedigital.com
Wed Apr 27 19:02:26 UTC 2022

Hi Marcel--

      As a macOS user, I like your solution to this.




      On 27/4/22 11:56, Marcel Taeumel wrote:

 > Hi all --
 > Primitive 126 (#primitiveDeferDisplayUpdates) has a problem. It has no
 > platform-specific code. So no platform-specific rendering backend (e.g.,
 > Metal) can communicate whether it actually supports deferred updates.
 > Because of this, we are forced to guess at the image level how to best
 > work with primitives 127 and 231.
 > Why is this bad? Because we must somehow reconfigure images for specific
 > VMs because those VMs do not tell whether primitive 126 has an effect or
 > not. So we have to guess. Maybe via using the #platformName. This is bad.
 > You can see the effects by Eliot's recent concern about Morphic's
 > window-dragging feature, which can only work right if we know how to
 > handle that extra video buffer in the image:
 > Well, the damage is done. Primitive 126 has been around like forever.
 > When the Metal support was introduced to the VM for macOS many years
 > ago, it broke the decent performance for all macOS users. It
 > overcommitted stuff to the video memory in primitives 127 and 231. As a
 > Windows user, I was always surprised that macOS users had to experience
 > such a sluggish Morphic performance.
 > Well, after years of complaints from macOS/Squeak users, I couldn't take
 > it anymore and fixed this regression in the recent OSVM. Of course you
 > now have to tell your favorite image that it *really* has to use an
 > image-side composition buffer. Recent images do that already
 > automatically. Fine. I even backported that to Squeak 5.3. For older
 > ones you do this:
 >     PasteUpMorph disableDeferredUpdates: true.
 >     Project allMorphicProjects do: [:ea | ea world canvas: nil].
 > Not that of an issue, one might think. But the VM is not fully backwards
 > compatible either. At least when looking at Morphic and its
 > window-dragging feature.
 > I don't think that we can change the past. Using the current OSVM with
 > older images would even require that simple in-image configuration if we
 > would adapt primitive 126. The code in WorldState >>
 > #displayWorld:submorphs: never really accounted for an actually working
 > primitive 126.
 > I am also not happy about this. I think that the original mistake was
 > made when primitive 126 was implemented without connecting it to
 > platform-specific code. But I do prefer a better performance over *not*
 > having to "flip a switch" in your favorite (older) image. Then, again, I
 > am a Windows user. Maybe other macOS users should share their thoughts
 > on this.
 > Backwards compatibility is hard. 99% might not be 100% but it is still
 > good.
 > Best,
 > Marcel

Craig Latta  ::  research computer scientist
Black Page Digital  ::  Berkeley, California
663137D7940BF5C0AFC :: 1349FB2ADA32C4D5314CE

More information about the Vm-dev mailing list