<div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:large">Hi Tobias,</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Oct 8, 2020 at 11:57 PM Tobias Pape <<a href="mailto:Das.Linux@gmx.de">Das.Linux@gmx.de</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">Hi<br>
<br>
> On 08.10.2020, at 19:58, Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</a>> wrote:<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>
<br>
Here's another idea:<br>
We already have<br>
<br>
DisplayScreen class>>actualScreenScaleFactor<br>
<primitive: 'primitiveScreenScaleFactor'><br>
^ 1.0<br>
<br>
And if we change DisplayScreen class>>startUp to<br>
<br>
DisplayScreen class>>startUp "DisplayScreen startUp"<br>
Display setScaleFactor: self actualScreenScaleFactor.<br>
Display setExtent: self actualScreenSize depth: Display nativeDepth.<br>
Display beDisplay<br></blockquote><div><br></div><div class="gmail_default" style="font-size:large">Very nice. Let's go with this.</div><div class="gmail_default" style="font-size:large"></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>
Then the contract could be:<br>
<br>
"Iff you call primitiveScreenScaleFactor before any call to primitive 106, then you opt in to possibly high dpi"<br>
<br>
That way, we do not have to change any image at all, cause older images just don't call that primitive.<br></blockquote><div><br></div><div class="gmail_default" style="font-size:large">Yep, works for me.</div><div class="gmail_default" style="font-size:large"></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>
<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>
Maybe a cmd-line parameter in any case…<br></blockquote><div><br></div><div class="gmail_default" style="font-size:large">+1</div><div class="gmail_default" style="font-size:large"></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>
> <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>
<br>
Funny. The mac vm says "/* This is invoked when the GC moves the display bitmap. For now do nothing. */" Does the GC ever do that actually?<br></blockquote><div><br></div><div class="gmail_default" style="font-size:large">Not now. It used to. One would see the pixels in the display become nonsense noise as the GC moved the display underneath the screen refresh. But now in Spur the beDisplay primitive pins the display bits.</div><div class="gmail_default" style="font-size:large"></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">
It's also fairly recent:<br>
<br>
78c402ea71ebcc9db12496f81021fdb9b57deb5f (Fri May 12 19:29:45 2017)<br>
<br>
StackInterpreter:<br>
Simplify and make robust display bitmap access for display update. The old code<br>
required platforms that needed to redraw at arbitrary times to have to access<br>
the display bits through interpreterProxy->displayObject, decoding it each time.<br>
There exists a small window during compaction, etc, during whiuch such access<br>
will fail and cause a VM crash. The new code provides four variables to<br>
reference the display, displayBits, displayWidth, displayHeight and<br>
displayDepth, which are assigned appropriately in the primitiveBeDisplay<br>
primitive. After a GC the interpreter checks if the displayBits have changed<br>
location and if so calls ioNoteDisplayChanged:width:height:depth:<br>
(ioNoteDisplayChangedwidthheightdepth) to inform the platform of the change<br>
(currently all platforms implement this as a null function).<br>
<br>
<br>
So, old (<2017) code cannot depend on it, new code does not. If the GC issue is moot, we can ditch it.<br></blockquote><div><br></div><div class="gmail_default" style="font-size:large"><font face="arial, sans-serif">Even if the GC does move the display, <span style="color:rgb(0,0,0);font-size:medium">ioNoteDisplayChangedwidthheig</span><span style="color:rgb(0,0,0);font-size:medium">htdepth</span> can't be called until after GC, which means that from the time the GC moves the display to the time the GC finishes, the display image is corrupted. That's fixed in Spur but in V3 you'll see that happen, especially if you resize the display (which allocates a new bitmap). At least on Mac I would see it regularly.</font></div><div class="gmail_default" style="font-size:large"></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>
<br>
Best regards<br>
-Tobias<br>
<br>
<br>
<br>
<br>
<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>