<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:large"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Oct 9, 2020 at 12:31 AM Fabio Niephaus <<a href="mailto:lists@fniephaus.com">lists@fniephaus.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"> <br>
Hi Eliot,<br>
<br>
What would be the consequences of moving the display creation logic<br>
from DisplayScreen class>>actualScreenSize to beDisplay? If beDisplay<br>
is called afterwards, it at least should be feasible, right?<br></blockquote><div><br></div><div class="gmail_default" style="font-size:large">I don't know.  There would need to be a design where the semantics of beDisplay were "Make me the display but set my size to whatever you think best".  But that's not how the interface is designed.  The interface is designed as</div><div class="gmail_default" style="font-size:large"><br></div><div class="gmail_default" style="font-size:large">1. tell Display how big <font face="arial, sans-serif">the <span style="color:rgb(0,0,0);font-size:medium">actual GUI's screen</span> is </font></div><div class="gmail_default" style="font-size:large">      => at this point the actual GUI's <span style="color:rgb(0,0,0);font-family:-webkit-standard;font-size:medium">screen</span> must be opened to find out how big it is</div><div class="gmail_default" style="font-size:large">2. Display adjusts itself accordingly</div><div class="gmail_default" style="font-size:large">3. beDisplay simply records the state that was actually started in 1.</div><div class="gmail_default" style="font-size:large"><br></div><div class="gmail_default" style="font-size:large">I don't know how to change this order without breaking backward-compatibility, which is where we came in.  Also, a deBisplay primitive which reached in and changed the inst vars in Display would be a really bad thing (IMO).</div><div class="gmail_default" style="font-size:large"><br></div><div class="gmail_default" style="font-size:large">So it seems to me that we're stuck with the<span style="font-family:arial,sans-serif;color:rgb(0,0,0)"> </span><span style="font-family:arial,sans-serif;color:rgb(0,0,0);font-size:medium">actual GUI's screen</span><span style="font-family:arial,sans-serif;color:rgb(0,0,0)"> being opened in DisplayScreen class>>actualScreenSize <primitive: 106></span></div><div class="gmail_default" style="font-size:large"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<br>
Cheers,<br>
Fabio<br>
<br>
On Thu, Oct 8, 2020 at 7:59 PM Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</a>> wrote:<br>
><br>
><br>
> Hi All,<br>
><br>
>     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.<br>
><br>
> 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).<br>
><br>
> 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:<br>
><br>
> DisplayScreen class>>actualScreenSize<br>
> <primitive: 106><br>
> ^ 640@480<br>
><br>
> becomes<br>
><br>
> DisplayScreen class>>actualScreenSize<br>
> self primitiveUseHighDPI: self useHighDPI. "where this is a preference"<br>
> ^self primitiveScreenSize<br>
><br>
> primitiveScreenSize<br>
> <primitive: 106><br>
> ^ 640@480<br>
><br>
><br>
> 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.<br>
><br>
><br>
> 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?<br>
> _,,,^..^,,,_<br>
> best, Eliot<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><span style="font-size:small;border-collapse:separate"><div>_,,,^..^,,,_<br></div><div>best, Eliot</div></span></div></div></div></div></div></div></div></div>