<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Hi Marcel,<br>
<br>
I was only aware about this today. I have also just read
<a class="moz-txt-link-freetext" href="http://lists.squeakfoundation.org/pipermail/vm-dev/2022-April/037766.html">http://lists.squeakfoundation.org/pipermail/vm-dev/2022-April/037766.html</a>
. 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!<br>
<br>
Cuis supports a separate in-image composition buffer if needed. But
it needs to know from the VM.<br>
<br>
The behavior Cuis assumes from primitive 126 is documented in
#primitiveDeferUpdates: that Cuis inherited from Squeak:<br>
- 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.<br>
- If "VM deferred updates" can not be set, meaning that writes are
propagated immediately, primitive 126 must fail.<br>
<br>
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.<br>
<br>
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.<br>
<br>
Thanks,<br>
<br>
On 4/27/2022 3:56 PM, Marcel Taeumel wrote:
<blockquote
cite="mid:Mailbird-f79e2054-e730-4e1e-9fa8-90cfe5eefe51@hpi.de"
type="cite">
<pre wrap=""> </pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<meta http-equiv="Context-Type" content="text/html; charset=utf-8">
<div>Hi all --
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>Because of this, we are forced to guess at the image level
how to best work with primitives 127 and 231.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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: <a moz-do-not-send="true"
href="http://lists.squeakfoundation.org/pipermail/vm-dev/2022-April/037887.html"><span>http://lists.squeakfoundation.org/pipermail/vm-dev/2022-April/037887.html</span></a></div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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:</div>
<div><br>
</div>
<div>
<div> PasteUpMorph disableDeferredUpdates: true.</div>
<div> Project allMorphicProjects do: [:ea | ea world canvas:
nil].</div>
</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>I am also not happy about this. <span>I think that the
original mistake was made when primitive 126 was implemented
without connecting it to platform-specific code. </span><span>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.</span></div>
<div><span><br>
</span></div>
<div><span>Backwards compatibility is hard. 99% might not be
100% but it is still good. </span></div>
<div><br>
</div>
<div>Best,</div>
<div>Marcel</div>
</div>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">--
Juan Vuletich
<a class="moz-txt-link-abbreviated" href="http://www.cuis-smalltalk.org">www.cuis-smalltalk.org</a>
<a class="moz-txt-link-freetext" href="https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev">https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev</a>
<a class="moz-txt-link-freetext" href="https://github.com/jvuletich">https://github.com/jvuletich</a>
<a class="moz-txt-link-freetext" href="https://www.linkedin.com/in/juan-vuletich-75611b3">https://www.linkedin.com/in/juan-vuletich-75611b3</a>
<a class="moz-txt-link-freetext" href="https://independent.academia.edu/JuanVuletich">https://independent.academia.edu/JuanVuletich</a>
<a class="moz-txt-link-freetext" href="https://www.researchgate.net/profile/Juan-Vuletich">https://www.researchgate.net/profile/Juan-Vuletich</a>
<a class="moz-txt-link-freetext" href="https://patents.justia.com/inventor/juan-manuel-vuletich">https://patents.justia.com/inventor/juan-manuel-vuletich</a>
<a class="moz-txt-link-freetext" href="https://twitter.com/JuanVuletich">https://twitter.com/JuanVuletich</a></pre>
</body>
</html>