(Thanks Tobias, for looking into this. I am not sure whether this is the right place to comment on this whole branch "krono/highdpi-v2" but here we go.)

For what it's worth, here is how I would design it in general to assure cross-platform compatibility and consider the pixel-based space we primarily access from within the image via Display (i.e., an instance of DisplayScreen, which is a Form, which has a Bitmap and a Color model). I am sure that you covered most of this already.

- On VM start-up and image-read time, create a platform-specific "surface" that is able to render the pixel space as reported from the image header in a window. - Do whatever is necessary to convert platform-specific units into pixels and back, which includes data from platform events such as mouse clicks. - Whenever the platform's "scale factor" changes, adapt your way of converting platform units into pixel units. - Whenever the platform's "scale factor" changes, feel free to resize the pixel space, but this can be also done from within the image via HostWindowPlugin support.

The image will constantly poll both actual screen size (primitive 106) and actual screen scale factor (primitive #primitiveScreenScaleFactor). When a change in either of those two values is detected, the image can then decide how to pass this on to whatever happens in the image. Nothing to worry about at the VM side. (I am sure that even semaphores can be implemented to make this change detection "on push" rather than "on pull," but this is out of scope here.)

That is, keep it simple. Yes, it may be that macOS has currently challenging rendering models in place that make it tricky to convert to/from pixels. But it's worth it. For the sake of modularity, simplicity, and compatibility. Note that Squeak Trunk (6.0alpha) is fully prepared for a working #primitiveScreenScaleFactor. It's just a VM (plugin) thing at this point.