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 at gmail.com>:


On Wed, Apr 27, 2022 at 12:19 AM Marcel Taeumel <marcel.taeumel at hpi.de [mailto:marcel.taeumel at 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 at gmail.com [mailto:eliot.miranda at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20220427/730934b5/attachment.html>