Hi All,

    ideally adding the high dpi support to the VM will not break
backwards-compatibility.  But that implies that the VM is informed before
it creates the display of whether to create a high dpi display or not.
Off-list Tobias asked me where the VM sets up the display on Mac and I was
surprised by the answer.

I thought it would be as part of beDisplay.  But it's actually as a
side-effect of DisplayScreen class>>actualScreenSize, primitive 106, which
calls the ioScreenSize function.  It is this functions' responsibility to
actually create the display, deriving the size from the savedWindowSize
info in the image header (which can or could be overridden on the VM
command line, and is when -headless is supplied).

So any new primitive added to allow DisplayScreen to inform the VM of
whether to use high dpi or not would have to be invoked before primitive
106.  So one way to implement this is to modify the chain of invocations
leading up to primitive 106.  For this route I'd like to propose the
following refactoring:

DisplayScreen class>>actualScreenSize
<primitive: 106>
^ 640 at 480

becomes

DisplayScreen class>>actualScreenSize
self primitiveUseHighDPI: self useHighDPI. "where this is a preference"
^self primitiveScreenSize

primitiveScreenSize
<primitive: 106>
^ 640 at 480


Another route is to make the useHighDPI flag part of the image header state
alongside the saved window size.  This would mean it was added to the flags
accessed via vmParameterAt: 48.  There could be a command-line argument to
override.


Finally I note that the beDisplay primitive simply stores the display
object in the specialObjectsArray and assigns the interpreter variables
that track the display, displayBits, displayWidth, displayHeight &
displayDepth.  It then invokes ioNoteDisplayChangedwidthheightdepth, but
*all* the implementations of this function are empty.  I propose that we
should eliminate 5this call and its implementation. It is confusing to
follow it and find it does nothing.  The argument could be that a platform
might require it.  But if that's so we can always put it back.  We have an
existence proof in all our platforms that this is unlikely.  Thoughts?
_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20201008/c889dfe9/attachment.html>