(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.

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.


Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.Message ID: <OpenSmalltalk/opensmalltalk-vm/commit/e9fc516352e98b1b0aed29aa2f0f64ae6738d489/68841757@github.com>