Squeak64-6.0 image has non-default display scale configuration

[LinqLover]

Description of the bug

The provided Squeak64-6.0 image is configured with a non-default display scale configuration. If you open the image in headful mode on a "normal" (i.e., non-high-DPI monitor), the scale factor will automatically be corrected during the first world cycle before the command line argument script is executed (see DisplayScreen class>>#checkForNewScreenScaleFactor and senders). However, in headless mode, this does not happen (presumably because primitiveScreenScaleFactor fails without a display and DisplayScreen>>#platformScaleFactor: early exits without updating/resetting the uiScaleFactor).

Affected images:

Only Squeak64-6.0 seems to be affected by the configuration drift. Squeak32-6.0 is fine, 5.3 and older are fine, Trunk images are fine.

Consequences of the bug

This non-default configuration involves multiple problems:

1. Tests may not expect a custom scale factor. For illustration, until recently, even some tests in the Trunk depended on the 100% mode and failed otherwise. This problem also affected the screenshot generation for SqueakByExample.

2. When the image is started in headful mode, the scale factor will be corrected automatically, but this involves an automatic change to the size of the host window, too (see UserInterfaceTheme>>#scaleMorphicWorldBy:). Not only may all this "flickering" confuse users who are debugging a smalltalkCI build, but also some X Servers for Linux cannot tolerate the primitiveHostWindowSizeSet invocation: My VcXsrv server for WSL 1, Windows 21H1, reproducibly crashes when the VM attempts to change the size of the host window. One might argue that this is not a direct debt of smalltalkCI, though. Still, it hinders users of WSL1 from debugging these smalltalkCI builds. :-)

   VcXsrv crash

   Extracting image...
   XIO:  fatal IO error 11 (Resource temporarily unavailable) on X server ":0.0"
         after 156 requests (156 known processed) with 1 events remaining.
   Error with status code 1:
   
   653 travis_wait /mnt/c/Users/Christoph/Documents/repos/hpi-swa/smalltalkCI/helpers.sh

Origin of the bug

I suppose that the non-default configuration is the result of manually installing the image on a Mac in headful mode:

$ squeak -vm-display-null TravisCI.image --evaluate '{FileDirectory default. Display platformScaleFactor. RealEstateAgent scaleFactor}'
...
{UnixFileDirectory on '/home/fniephaus/Downloads/Squeak6.0-22104-64bit-202206021410-Linux-x64/Squeak6.0-22104-64bit-202206021410-Linux-x64/shared' . 1.25 . 1.3571428571428572}

Possible solutions

The image can be fixed by reopening the image in headful mode on a normal-DPI screen in Windows and re-saving it. I dare to claim that the issue would not have occured if the image would have been set up in a completely automated process by a CI. :-)

As a workaround, I have added the following preTesting script to my .smalltalk.ston file:

Display uiScaleFactor: 1.0; flag: #workaround. "smalltalkCI: default scale factor in Squeak64-6.0 image is wrong (https://github.com/hpi-swa/smalltalkCI/issues/569)"

I think that the right solution to fix the issue would be to recreate/correct the image as described above and update the release.

---

tl;dr: @fniephaus Could you update the Squeak64-6.0 image with a regular 100% uiScaleFactor? If there is any chance I can help you with this, please let me know :)

/cc @marceltaeumel FYI of the mentioned scaling behavior in Squeak. While I am sure that the smalltalkCI image should indeed use a standard scaling factor, is it intended behavior that the uiScaleFactor is not reset when the image is started in headless mode?

[fniephaus]

Sounds like this is something we should fix but I'm afraid it won't happen this week. I'm now sure we can automate image updates completely, but maybe some of it can be automated.

[LinqLover]

No hurry because there is a workaround. :)