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

[Juan Vuletich]

Hi Marcel,

I was only aware about this today. I have also just read 
http://lists.squeakfoundation.org/pipermail/vm-dev/2022-April/037766.html . 
WRT "Tested with **Squeak6.0alpha** and **Cuis6.0-5069**.", let me thank 
you all for considering Cuis a first-class citizen of the OpenSmalltalk 
world!

Cuis supports a separate in-image composition buffer if needed. But it 
needs to know from the VM.

The behavior Cuis assumes from primitive 126 is documented in 
#primitiveDeferUpdates: that Cuis inherited from Squeak:
- The primitive allows requesting to enable or disable VM deferred 
updates. Disable means framebuffer is updated on every write, with 
possible flickering unless a separate composition buffer is used in the 
image.
- If "VM deferred updates" can not be set, meaning that writes are 
propagated immediately, primitive 126 must fail.

In OpenSmalltalk Linux and Windows VMs, primitive 126 doesn't fail, but 
in-image double buffering is not needed. The same happened with Mac 
previous VMs.

The behavior of the 202204190959 Mac VM appears to be that deferred 
updates are not set even if requested (via prim 126), but prim 126 
doesn't fail. This produces a bit of flickering in Cuis, that can't be 
easily avoided, because Cuis can't know. If primitive 126 is made to 
fail, Cuis will be happy again. Otherwise we'd need another way for the 
image to know. I'm willing to adapt Cuis as needed.

Thanks,

On 4/27/2022 3:56 PM, 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: 
> http://lists.squeakfoundation.org/pipermail/vm-dev/2022-April/037887.html
>
> 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


-- 
Juan Vuletich
www.cuis-smalltalk.org
https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev
https://github.com/jvuletich
https://www.linkedin.com/in/juan-vuletich-75611b3
https://independent.academia.edu/JuanVuletich
https://www.researchgate.net/profile/Juan-Vuletich
https://patents.justia.com/inventor/juan-manuel-vuletich
https://twitter.com/JuanVuletich

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20220427/11919350/attachment-0001.html>