[Vm-dev] Primitive 126 | Its problems and its future :-)
craig at blackpagedigital.com
Wed Apr 27 19:02:26 UTC 2022
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
Craig Latta :: research computer scientist
Black Page Digital :: Berkeley, California
663137D7940BF5C0AFC :: 1349FB2ADA32C4D5314CE
More information about the Vm-dev