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 [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
Hi Marcel--
As a macOS user, I like your solution to this.
thanks!
-C
***
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:
http://lists.squeakfoundation.org/pipermail/vm-dev/2022-April/037887.html 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
-- Craig Latta :: research computer scientist Black Page Digital :: Berkeley, California 663137D7940BF5C0AFC :: 1349FB2ADA32C4D5314CE
Please let's talk live on this; email is crap for debating this sort of thing and far too often just gets everyone cross.
Whilst it's certainly true that the prim 126 has failed to return any useful flag value since at least 1998 (the earliest mention I have in email/source) it *does* set a value that is freely available to platform specific code. Mind you, the value is not initialised by default, which could cause much fun.
The only platform code I see that does reference it is Windows in ioForceDisplayUpdate(). Many platform versions of that do nothing, others actually move bits.
Given that this flag appears to be ignored in Mac code, how is it involved in the window dragging?
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: XYZZY: Branch and Play Adventure
Hi Tim --
Given that this flag appears to be ignored in Mac code, how is it involved in the window dragging?
The image always tries to set this flag to "true", the primitive 126 never fails. So the image assumes that deferred updating is supported.
After drawing all morphs onto Display, the patch under the HandMorph is then saved. Then the HandMorph (and the submorphs/windows it is dragging) will be drawn onto Display. Then that saved patch will be restored BUT without telling the VM via primitive 127.
Then the image is done and tells the VM to show everything on the video buffer. Without proper support of primitive 126, the VM platform code starts reading the displayBits directly only then. That is, without deferred updating, that saved patch under the HandMorph is already restored when the graphics backend starts reading the displayBits.
That's why the entire thing becomes invisible. Does not affect HandMorph without dragging anything because we show a hardware cursor then.
Dragging via Morphic halo is also not affected because the hardware cursor will still be used and the morph directly be moved.
The entire thing is a performance optimization because the HandMorph caches the pixels of the submorphs it drags.
Best, Marcel Am 27.04.2022 23:49:51 schrieb tim Rowledge tim@rowledge.org:
Please let's talk live on this; email is crap for debating this sort of thing and far too often just gets everyone cross.
Whilst it's certainly true that the prim 126 has failed to return any useful flag value since at least 1998 (the earliest mention I have in email/source) it *does* set a value that is freely available to platform specific code. Mind you, the value is not initialised by default, which could cause much fun.
The only platform code I see that does reference it is Windows in ioForceDisplayUpdate(). Many platform versions of that do nothing, others actually move bits.
Given that this flag appears to be ignored in Mac code, how is it involved in the window dragging?
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: XYZZY: Branch and Play Adventure
Thanks for this detailed explanation, Marcel. It really helps.
Cheers,
On 4/28/2022 4:40 AM, Marcel Taeumel wrote:
Hi Tim --
Given that this flag appears to be ignored in Mac code, how is it involved in the window dragging?
The image always tries to set this flag to "true", the primitive 126 never fails. So the image assumes that deferred updating is supported.
After drawing all morphs onto Display, the patch under the HandMorph is then saved. Then the HandMorph (and the submorphs/windows it is dragging) will be drawn onto Display. Then that saved patch will be restored BUT without telling the VM via primitive 127.
Then the image is done and tells the VM to show everything on the video buffer. Without proper support of primitive 126, the VM platform code starts reading the displayBits directly only then. That is, without deferred updating, that saved patch under the HandMorph is already restored when the graphics backend starts reading the displayBits.
That's why the entire thing becomes invisible. Does not affect HandMorph without dragging anything because we show a hardware cursor then.
Dragging via Morphic halo is also not affected because the hardware cursor will still be used and the morph directly be moved.
The entire thing is a performance optimization because the HandMorph caches the pixels of the submorphs it drags.
Best, Marcel
Am 27.04.2022 23:49:51 schrieb tim Rowledge tim@rowledge.org:
Please let's talk live on this; email is crap for debating this sort of thing and far too often just gets everyone cross.
Whilst it's certainly true that the prim 126 has failed to return any useful flag value since at least 1998 (the earliest mention I have in email/source) it *does* set a value that is freely available to platform specific code. Mind you, the value is not initialised by default, which could cause much fun.
The only platform code I see that does reference it is Windows in ioForceDisplayUpdate(). Many platform versions of that do nothing, others actually move bits.
Given that this flag appears to be ignored in Mac code, how is it involved in the window dragging?
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: XYZZY: Branch and Play Adventure
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
Hi Juan --
If primitive 126 is made to fail, Cuis will be happy again. Otherwise we'd need another way for the image to know.
Squeak's current approach is to just check for being on the macOS platform, which also works for older VMs (because the image-side composition buffer fixes some of the performance regressions but not that 60 FPS cap).
Smalltalk platformName = 'Mac OS'.
Primitive 126 could be improved if we would attach platform-specific code to it. Might be a "true" for most backends. I will open issues in the OSVM repo for this.
Best, Marcel Am 28.04.2022 00:20:29 schrieb Juan Vuletich juanvuletich@zoho.com: 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 [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 [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 [http://www.cuis-smalltalk.org] https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev [https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev] https://github.com/jvuletich [https://github.com/jvuletich] https://www.linkedin.com/in/juan-vuletich-75611b3 [https://www.linkedin.com/in/juan-vuletich-75611b3] https://independent.academia.edu/JuanVuletich [https://independent.academia.edu/JuanVuletich] https://www.researchgate.net/profile/Juan-Vuletich [https://www.researchgate.net/profile/Juan-Vuletich] https://patents.justia.com/inventor/juan-manuel-vuletich [https://patents.justia.com/inventor/juan-manuel-vuletich] https://twitter.com/JuanVuletich [https://twitter.com/JuanVuletich]
Hi Marcel,
The check for 'MacOS' is an acceptable solution for Cuis.
But I just did a quick test with Squeak 5.3, running on the new VM. If I comment the primitive 126 call in #primitiveDeferUpdates: , to simulate the effect of the primitive failing (and resize the squeak window to force recreation of Display, Canvas, etc), then the "invisible dragged window" problem is fixed.
As I said before, this is also a good solution for Cuis. So, my suggestion, is to simply make primitive 126 fail on MacOs.
This wouldn't affect older images checking for the platform (as you say, for a performance improvement), but would fix older "untweaked" images, solving any concern about strict back compatibility for the VM.
Thanks,
On 4/28/2022 4:28 AM, Marcel Taeumel wrote:
Hi Juan --
If primitive 126 is made to fail, Cuis will be happy again. Otherwise we'd need another way for the image to know.
Squeak's current approach is to just check for being on the macOS platform, which also works for older VMs (because the image-side composition buffer fixes some of the performance regressions but not that 60 FPS cap).
Smalltalk platformName = 'Mac OS'.
Primitive 126 could be improved if we would attach platform-specific code to it. Might be a "true" for most backends. I will open issues in the OSVM repo for this.
Best, Marcel
vm-dev@lists.squeakfoundation.org
-
Craig Latta -
Juan Vuletich -
Marcel Taeumel -
tim Rowledge