Hi Marcel,
the issue of windows being invisible when dragged in the new VM is a major bug. The VM needs to be backwards compatible. It souldn't break old images. So we need to find a way of restoring the default behaviour in images that don't set the relevant preference.
To reproduce take e.g. Squeak 6.0 alpha or the ;ast of the 5.x line and simply try and move a window about As soon as the window starts to move it disappears and then reappears when the mouse button is released. This must be fixed. _,,,^..^,,,_ best, Eliot
Hi Eliot --
No, this cannot be preserved on the VM side without again introducing that major performance regression that has been there for several years now on the macOS platform. I strongly argue that we keep the VM platform code this way.
However, it can *very easily* be fixed in most (if not all) older images. Just disable deferred (display) updates as it was not supported on macOS for a very (!) long time:
PasteUpMorph disableDeferredUpdates: true. Project allMorphicProjects do: [:ea | ea world canvas: nil].
To reproduce take e.g. Squeak 6.0 alpha [...]
No, Squeak6.0alpha (Trunk) does not show this issue unless it is not an updated image. Still, this update has been part of the update stream for several weeks now.
[...] or the ;ast of the 5.x line [...]
The above snippet accounts for this *very easily*. It even works in Squeak 4.x. This is an image-side thing. It always has been. Since 1999. This is not a VM issue.
Best,
Marcel
P.S.: Keep in mind that ST80-style "Fast dragging" is always an alternative in older images: Preferences enable: #fastDragWindowForMorphic. Am 27.04.2022 03:29:31 schrieb Eliot Miranda eliot.miranda@gmail.com: Hi Marcel,
the issue of windows being invisible when dragged in the new VM is a major bug. The VM needs to be backwards compatible. It souldn't break old images. So we need to find a way of restoring the default behaviour in images that don't set the relevant preference.
To reproduce take e.g. Squeak 6.0 alpha or the ;ast of the 5.x line and simply try and move a window about As soon as the window starts to move it disappears and then reappears when the mouse button is released. This must be fixed. _,,,^..^,,,_ best, Eliot
Hi Marcel,
the issue of windows being invisible when dragged in the new VM is a major bug. The VM needs to be backwards compatible. It souldn't break old images. So we need to find a way of restoring the default behaviour in images that don't set the relevant preference.
To reproduce take e.g. Squeak 6.0 alpha or the ;ast of the 5.x line and simply try and move a window about As soon as the window starts to move it disappears and then reappears when the mouse button is released. This must be fixed. _,,,^..^,,,_
best, Eliot
Hi all --
In addition to my previous response, we can schedule a Zoom/Jitsi session if you want me to go into more details what the overall issue here is.
Otherwise, I documented the situation in the code:
https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/97324043f5749da751ad2...
https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/97324043f5749da751ad2...
https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/620
During the last years, we had so many complaints about the Morphic performance on macOS in our University courses. This fix is overdue and very (!) valuable.
Again, this is an image-side concern. It's not a VM issue. Backwards compatibility can *very easily* be preserved in older images from within those images. See my previous response here.
Best, Marcel Am 27.04.2022 09:19:12 schrieb Marcel Taeumel marcel.taeumel@hpi.de: Hi Eliot --
No, this cannot be preserved on the VM side without again introducing that major performance regression that has been there for several years now on the macOS platform. I strongly argue that we keep the VM platform code this way.
However, it can *very easily* be fixed in most (if not all) older images. Just disable deferred (display) updates as it was not supported on macOS for a very (!) long time:
PasteUpMorph disableDeferredUpdates: true. Project allMorphicProjects do: [:ea | ea world canvas: nil].
To reproduce take e.g. Squeak 6.0 alpha [...]
No, Squeak6.0alpha (Trunk) does not show this issue unless it is not an updated image. Still, this update has been part of the update stream for several weeks now.
[...] or the ;ast of the 5.x line [...]
The above snippet accounts for this *very easily*. It even works in Squeak 4.x. This is an image-side thing. It always has been. Since 1999. This is not a VM issue.
Best,
Marcel
P.S.: Keep in mind that ST80-style "Fast dragging" is always an alternative in older images: Preferences enable: #fastDragWindowForMorphic. Am 27.04.2022 03:29:31 schrieb Eliot Miranda eliot.miranda@gmail.com: Hi Marcel,
the issue of windows being invisible when dragged in the new VM is a major bug. The VM needs to be backwards compatible. It souldn't break old images. So we need to find a way of restoring the default behaviour in images that don't set the relevant preference.
To reproduce take e.g. Squeak 6.0 alpha or the ;ast of the 5.x line and simply try and move a window about As soon as the window starts to move it disappears and then reappears when the mouse button is released. This must be fixed. _,,,^..^,,,_ best, Eliot
Hi Marcel,
the issue of windows being invisible when dragged in the new VM is a major bug. The VM needs to be backwards compatible. It souldn't break old images. So we need to find a way of restoring the default behaviour in images that don't set the relevant preference.
To reproduce take e.g. Squeak 6.0 alpha or the ;ast of the 5.x line and simply try and move a window about As soon as the window starts to move it disappears and then reappears when the mouse button is released. This must be fixed. _,,,^..^,,,_
best, Eliot
Hi all --
One more thing. :-)
The compatibility fix for the macOS platform for the newest OSVM got already backported to Squeak 5.3. Just hit the update button. It is not that hard.
I can backport this to Squeak 5.2 and 5.1 as well if you want me to do so.
Best, Marcel Am 27.04.2022 09:55:50 schrieb Marcel Taeumel marcel.taeumel@hpi.de: Hi all --
In addition to my previous response, we can schedule a Zoom/Jitsi session if you want me to go into more details what the overall issue here is.
Otherwise, I documented the situation in the code:
https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/97324043f5749da751ad2...
https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/97324043f5749da751ad2...
https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/620
During the last years, we had so many complaints about the Morphic performance on macOS in our University courses. This fix is overdue and very (!) valuable.
Again, this is an image-side concern. It's not a VM issue. Backwards compatibility can *very easily* be preserved in older images from within those images. See my previous response here.
Best, Marcel Am 27.04.2022 09:19:12 schrieb Marcel Taeumel marcel.taeumel@hpi.de: Hi Eliot --
No, this cannot be preserved on the VM side without again introducing that major performance regression that has been there for several years now on the macOS platform. I strongly argue that we keep the VM platform code this way.
However, it can *very easily* be fixed in most (if not all) older images. Just disable deferred (display) updates as it was not supported on macOS for a very (!) long time:
PasteUpMorph disableDeferredUpdates: true. Project allMorphicProjects do: [:ea | ea world canvas: nil].
To reproduce take e.g. Squeak 6.0 alpha [...]
No, Squeak6.0alpha (Trunk) does not show this issue unless it is not an updated image. Still, this update has been part of the update stream for several weeks now.
[...] or the ;ast of the 5.x line [...]
The above snippet accounts for this *very easily*. It even works in Squeak 4.x. This is an image-side thing. It always has been. Since 1999. This is not a VM issue.
Best,
Marcel
P.S.: Keep in mind that ST80-style "Fast dragging" is always an alternative in older images: Preferences enable: #fastDragWindowForMorphic. Am 27.04.2022 03:29:31 schrieb Eliot Miranda eliot.miranda@gmail.com: Hi Marcel,
the issue of windows being invisible when dragged in the new VM is a major bug. The VM needs to be backwards compatible. It souldn't break old images. So we need to find a way of restoring the default behaviour in images that don't set the relevant preference.
To reproduce take e.g. Squeak 6.0 alpha or the ;ast of the 5.x line and simply try and move a window about As soon as the window starts to move it disappears and then reappears when the mouse button is released. This must be fixed. _,,,^..^,,,_ best, Eliot
Hi Marcel,
the issue of windows being invisible when dragged in the new VM is a major bug. The VM needs to be backwards compatible. It souldn't break old images. So we need to find a way of restoring the default behaviour in images that don't set the relevant preference.
To reproduce take e.g. Squeak 6.0 alpha or the ;ast of the 5.x line and simply try and move a window about As soon as the window starts to move it disappears and then reappears when the mouse button is released. This must be fixed. _,,,^..^,,,_
best, Eliot
On Wed, Apr 27, 2022 at 12:56 AM Marcel Taeumel marcel.taeumel@hpi.de wrote:
Hi all --
In addition to my previous response, we can schedule a Zoom/Jitsi session if you want me to go into more details what the overall issue here is.
Otherwise, I documented the situation in the code:
https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/97324043f5749da751ad2...
https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/97324043f5749da751ad2...
https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/620
During the last years, we had so many complaints about the Morphic performance on macOS in our University courses. This fix is overdue and very (!) valuable.
Again, this is an image-side concern. It's not a VM issue. Backwards compatibility can *very easily* be preserved in older images from within those images. See my previous response here.
One cannot redefine backwards compatibility to mean "you have to change old images to run on the new VM". Backwards compatibility of the VM implies that old images continue to run *without change* and without change in semantics.
Best, Marcel
Am 27.04.2022 09:19:12 schrieb Marcel Taeumel marcel.taeumel@hpi.de: Hi Eliot --
No, this cannot be preserved on the VM side without again introducing that major performance regression that has been there for several years now on the macOS platform. I strongly argue that we keep the VM platform code this way.
However, it can *very easily* be fixed in most (if not all) older images. Just disable deferred (display) updates as it was not supported on macOS for a very (!) long time:
PasteUpMorph disableDeferredUpdates: true. Project allMorphicProjects do: [:ea | ea world canvas: nil].
To reproduce take e.g. Squeak 6.0 alpha [...]
No, Squeak6.0alpha (Trunk) does not show this issue unless it is not an updated image. Still, this update has been part of the update stream for several weeks now.
[...] or the ;ast of the 5.x line [...]
The above snippet accounts for this *very easily*. It even works in Squeak 4.x. This is an image-side thing. It always has been. Since 1999. This is not a VM issue.
Best, Marcel
P.S.: Keep in mind that ST80-style "Fast dragging" is always an alternative in older images: Preferences enable: #fastDragWindowForMorphic.
Am 27.04.2022 03:29:31 schrieb Eliot Miranda eliot.miranda@gmail.com: Hi Marcel,
the issue of windows being invisible when dragged in the new VM is a major bug. The VM needs to be backwards compatible. It souldn't break old images. So we need to find a way of restoring the default behaviour in images that don't set the relevant preference.
To reproduce take e.g. Squeak 6.0 alpha or the ;ast of the 5.x line and simply try and move a window about As soon as the window starts to move it disappears and then reappears when the mouse button is released. This must be fixed. _,,,^..^,,,_ best, Eliot Hi Marcel,
the issue of windows being invisible when dragged in the new VM is a
major bug. The VM needs to be backwards compatible. It souldn't break old images. So we need to find a way of restoring the default behaviour in images that don't set the relevant preference.
To reproduce take e.g. Squeak 6.0 alpha or the ;ast of the 5.x line and simply try and move a window about As soon as the window starts to move it disappears and then reappears when the mouse button is released. This must be fixed. _,,,^..^,,,_ best, Eliot
Hi Eliot --
Backwards compatibility of the VM implies that old images continue to run *without change* and without change in semantics.
Haha. Funny. Tell that all the macOS users and their old 32-bit images.
Of course this is a trade-off. The best we can manage at the moment.
I strongly argue to not make the VM slow again on macOS. I am not sure why you would even want that.
Best, Marcel Am 27.04.2022 20:08:30 schrieb Eliot Miranda eliot.miranda@gmail.com:
On Wed, Apr 27, 2022 at 12:56 AM Marcel Taeumel <marcel.taeumel@hpi.de [mailto:marcel.taeumel@hpi.de]> wrote:
Hi all --
In addition to my previous response, we can schedule a Zoom/Jitsi session if you want me to go into more details what the overall issue here is.
Otherwise, I documented the situation in the code:
https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/97324043f5749da751ad2... [https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/97324043f5749da751ad2...]
https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/97324043f5749da751ad2... [https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/97324043f5749da751ad2...]
https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/620 [https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/620]
During the last years, we had so many complaints about the Morphic performance on macOS in our University courses. This fix is overdue and very (!) valuable.
Again, this is an image-side concern. It's not a VM issue. Backwards compatibility can *very easily* be preserved in older images from within those images. See my previous response here.
One cannot redefine backwards compatibility to mean "you have to change old images to run on the new VM". Backwards compatibility of the VM implies that old images continue to run *without change* and without change in semantics.
Best, Marcel Am 27.04.2022 09:19:12 schrieb Marcel Taeumel <marcel.taeumel@hpi.de [mailto:marcel.taeumel@hpi.de]>: Hi Eliot --
No, this cannot be preserved on the VM side without again introducing that major performance regression that has been there for several years now on the macOS platform. I strongly argue that we keep the VM platform code this way.
However, it can *very easily* be fixed in most (if not all) older images. Just disable deferred (display) updates as it was not supported on macOS for a very (!) long time:
PasteUpMorph disableDeferredUpdates: true. Project allMorphicProjects do: [:ea | ea world canvas: nil].
To reproduce take e.g. Squeak 6.0 alpha [...]
No, Squeak6.0alpha (Trunk) does not show this issue unless it is not an updated image. Still, this update has been part of the update stream for several weeks now.
[...] or the ;ast of the 5.x line [...]
The above snippet accounts for this *very easily*. It even works in Squeak 4.x. This is an image-side thing. It always has been. Since 1999. This is not a VM issue.
Best,
Marcel
P.S.: Keep in mind that ST80-style "Fast dragging" is always an alternative in older images: Preferences enable: #fastDragWindowForMorphic. Am 27.04.2022 03:29:31 schrieb Eliot Miranda <eliot.miranda@gmail.com [mailto:eliot.miranda@gmail.com]>: Hi Marcel,
the issue of windows being invisible when dragged in the new VM is a major bug. The VM needs to be backwards compatible. It souldn't break old images. So we need to find a way of restoring the default behaviour in images that don't set the relevant preference.
To reproduce take e.g. Squeak 6.0 alpha or the ;ast of the 5.x line and simply try and move a window about As soon as the window starts to move it disappears and then reappears when the mouse button is released. This must be fixed. _,,,^..^,,,_ best, Eliot
Hi Marcel,
the issue of windows being invisible when dragged in the new VM is a major bug. The VM needs to be backwards compatible. It souldn't break old images. So we need to find a way of restoring the default behaviour in images that don't set the relevant preference.
To reproduce take e.g. Squeak 6.0 alpha or the ;ast of the 5.x line and simply try and move a window about As soon as the window starts to move it disappears and then reappears when the mouse button is released. This must be fixed. _,,,^..^,,,_
best, Eliot
--
_,,,^..^,,,_
best, Eliot
On Wed, Apr 27, 2022 at 12:19 AM Marcel Taeumel marcel.taeumel@hpi.de wrote:
Hi Eliot --
No, this cannot be preserved on the VM side without again introducing that major performance regression that has been there for several years now on the macOS platform. I strongly argue that we keep the VM platform code this way.
You *cannot* just break older images. This constitutes a fork in the VM.
However, it can *very easily* be fixed in most (if not all) older images. Just disable deferred (display) updates as it was not supported on macOS for a very (!) long time:
PasteUpMorph disableDeferredUpdates: true. Project allMorphicProjects do: [:ea | ea world canvas: nil].
If it can be fixed easily at the image level then it can be fixed at the VM level, for example, by adding a status bit to new images which invokes the new behaviour in the VM. Haivng to modify old images is ass backwards.;
To reproduce take e.g. Squeak 6.0 alpha [...]
No, Squeak6.0alpha (Trunk) does not show this issue unless it is not an updated image. Still, this update has been part of the update stream for several weeks now.
[...] or the ;ast of the 5.x line [...]
The above snippet accounts for this *very easily*. It even works in Squeak 4.x. This is an image-side thing. It always has been. Since 1999. This is not a VM issue.
Best, Marcel
P.S.: Keep in mind that ST80-style "Fast dragging" is always an alternative in older images: Preferences enable: #fastDragWindowForMorphic.
Am 27.04.2022 03:29:31 schrieb Eliot Miranda eliot.miranda@gmail.com: Hi Marcel,
the issue of windows being invisible when dragged in the new VM is a major bug. The VM needs to be backwards compatible. It souldn't break old images. So we need to find a way of restoring the default behaviour in images that don't set the relevant preference.
To reproduce take e.g. Squeak 6.0 alpha or the ;ast of the 5.x line and simply try and move a window about As soon as the window starts to move it disappears and then reappears when the mouse button is released. This must be fixed. _,,,^..^,,,_ best, Eliot Hi Marcel,
the issue of windows being invisible when dragged in the new VM is a
major bug. The VM needs to be backwards compatible. It souldn't break old images. So we need to find a way of restoring the default behaviour in images that don't set the relevant preference.
To reproduce take e.g. Squeak 6.0 alpha or the ;ast of the 5.x line and simply try and move a window about As soon as the window starts to move it disappears and then reappears when the mouse button is released. This must be fixed. _,,,^..^,,,_ best, Eliot
Hi Eliot --
You are just talking about a feature specific to Morphic. Let's not forget about that. ;-)
Best, Marcel Am 27.04.2022 19:58:24 schrieb Eliot Miranda eliot.miranda@gmail.com:
On Wed, Apr 27, 2022 at 12:19 AM Marcel Taeumel <marcel.taeumel@hpi.de [mailto:marcel.taeumel@hpi.de]> wrote:
Hi Eliot --
No, this cannot be preserved on the VM side without again introducing that major performance regression that has been there for several years now on the macOS platform. I strongly argue that we keep the VM platform code this way.
You *cannot* just break older images. This constitutes a fork in the VM.
However, it can *very easily* be fixed in most (if not all) older images. Just disable deferred (display) updates as it was not supported on macOS for a very (!) long time:
PasteUpMorph disableDeferredUpdates: true. Project allMorphicProjects do: [:ea | ea world canvas: nil].
If it can be fixed easily at the image level then it can be fixed at the VM level, for example, by adding a status bit to new images which invokes the new behaviour in the VM. Haivng to modify old images is ass backwards.;
To reproduce take e.g. Squeak 6.0 alpha [...]
No, Squeak6.0alpha (Trunk) does not show this issue unless it is not an updated image. Still, this update has been part of the update stream for several weeks now.
[...] or the ;ast of the 5.x line [...]
The above snippet accounts for this *very easily*. It even works in Squeak 4.x. This is an image-side thing. It always has been. Since 1999. This is not a VM issue.
Best,
Marcel
P.S.: Keep in mind that ST80-style "Fast dragging" is always an alternative in older images: Preferences enable: #fastDragWindowForMorphic. Am 27.04.2022 03:29:31 schrieb Eliot Miranda <eliot.miranda@gmail.com [mailto:eliot.miranda@gmail.com]>: Hi Marcel,
the issue of windows being invisible when dragged in the new VM is a major bug. The VM needs to be backwards compatible. It souldn't break old images. So we need to find a way of restoring the default behaviour in images that don't set the relevant preference.
To reproduce take e.g. Squeak 6.0 alpha or the ;ast of the 5.x line and simply try and move a window about As soon as the window starts to move it disappears and then reappears when the mouse button is released. This must be fixed. _,,,^..^,,,_ best, Eliot
Hi Marcel,
the issue of windows being invisible when dragged in the new VM is a major bug. The VM needs to be backwards compatible. It souldn't break old images. So we need to find a way of restoring the default behaviour in images that don't set the relevant preference.
To reproduce take e.g. Squeak 6.0 alpha or the ;ast of the 5.x line and simply try and move a window about As soon as the window starts to move it disappears and then reappears when the mouse button is released. This must be fixed. _,,,^..^,,,_
best, Eliot
--
_,,,^..^,,,_
best, Eliot
Hi Eliot --
You *cannot* just break older images. This constitutes a fork in the VM.
Well, I did not. And it is not. We seem to have a different idea on the severity of this change.
It is not viable to introduce a bit in the image header for a feature in Morphic that can already be configured since 1999. That would be kind of crazy. ;-)
Again, older images are not broken.
Well, I can flip the pointer and say that the VM broke the image when Metal-support was introduced years ago without maintaining a proper video cache on its own. THAT was even worse because it broke all images for macOS in the sense that it made Morphic really slow.
So I finally fixed the regression. This is bogus. Potato, potato. :-)
Best, Marcel
P.S.: This thing here is way (!) less problematic than the current 64-bit OSVM not being able to just open 32-bit images. Now that I would call a breaking change that was not quite necessary. =) Am 27.04.2022 19:58:24 schrieb Eliot Miranda eliot.miranda@gmail.com:
On Wed, Apr 27, 2022 at 12:19 AM Marcel Taeumel <marcel.taeumel@hpi.de [mailto:marcel.taeumel@hpi.de]> wrote:
Hi Eliot --
No, this cannot be preserved on the VM side without again introducing that major performance regression that has been there for several years now on the macOS platform. I strongly argue that we keep the VM platform code this way.
You *cannot* just break older images. This constitutes a fork in the VM.
However, it can *very easily* be fixed in most (if not all) older images. Just disable deferred (display) updates as it was not supported on macOS for a very (!) long time:
PasteUpMorph disableDeferredUpdates: true. Project allMorphicProjects do: [:ea | ea world canvas: nil].
If it can be fixed easily at the image level then it can be fixed at the VM level, for example, by adding a status bit to new images which invokes the new behaviour in the VM. Haivng to modify old images is ass backwards.;
To reproduce take e.g. Squeak 6.0 alpha [...]
No, Squeak6.0alpha (Trunk) does not show this issue unless it is not an updated image. Still, this update has been part of the update stream for several weeks now.
[...] or the ;ast of the 5.x line [...]
The above snippet accounts for this *very easily*. It even works in Squeak 4.x. This is an image-side thing. It always has been. Since 1999. This is not a VM issue.
Best,
Marcel
P.S.: Keep in mind that ST80-style "Fast dragging" is always an alternative in older images: Preferences enable: #fastDragWindowForMorphic. Am 27.04.2022 03:29:31 schrieb Eliot Miranda <eliot.miranda@gmail.com [mailto:eliot.miranda@gmail.com]>: Hi Marcel,
the issue of windows being invisible when dragged in the new VM is a major bug. The VM needs to be backwards compatible. It souldn't break old images. So we need to find a way of restoring the default behaviour in images that don't set the relevant preference.
To reproduce take e.g. Squeak 6.0 alpha or the ;ast of the 5.x line and simply try and move a window about As soon as the window starts to move it disappears and then reappears when the mouse button is released. This must be fixed. _,,,^..^,,,_ best, Eliot
Hi Marcel,
the issue of windows being invisible when dragged in the new VM is a major bug. The VM needs to be backwards compatible. It souldn't break old images. So we need to find a way of restoring the default behaviour in images that don't set the relevant preference.
To reproduce take e.g. Squeak 6.0 alpha or the ;ast of the 5.x line and simply try and move a window about As soon as the window starts to move it disappears and then reappears when the mouse button is released. This must be fixed. _,,,^..^,,,_
best, Eliot
--
_,,,^..^,,,_
best, Eliot
vm-dev@lists.squeakfoundation.org