[Vm-dev] HiDpi support in MacOS

[Juan Vuletich]

Hi Marcel,

One small comment is that factors others than 1.0 or 2.0 are not an 
"older" form of scaling, but what latest MacOS does today on the latest 
apple hardware.

Anyway It seems it can not be done. See 
https://stackoverflow.com/questions/53551692/how-to-render-each-pixel-of-a-bitmap-texture-to-each-native-physical-pixel-of-th#53563363 
. Metal insists on an internal 2x buffer and resampling everything.

So, having a higher resolution in Smalltalk's Display than physical 
screen will waste some RAM and create slight downscaling artifacts, but 
it is indeed better than using lower resolution Smalltalk Display and 
have worse upscaling artifacts.

Besides, knowledgeable users can set their MacOS display to "half 
resolution" (actually the default) or use EasyRes or the like to set 
MacOS display to full retina resolution. Both this options give a 
Smalltalk display with true LCD physical resolution.

In short, I think the current behavior is the best we can have on MacOS.

Thanks,

On 4/28/2022 5:18 AM, Marcel Taeumel wrote:
> Hi all --
>
> I documented this 
> here: https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/628
>
> Best,
> Marcel
>>
>> Am 28.04.2022 09:51:22 schrieb Marcel Taeumel <marcel.taeumel at hpi.de>:
>>
>> Hi Juan --
>>
>> Currently, we only use the backingScaleFactor. For current systems 
>> this can only ever be 1.0 or 2.0. I have yet to discover the macOS 
>> API that let's us work with native pixels for that other (older) form 
>> other scaling on macOS.
>>
>> I will open an issue for that.
>>
>> Best,
>> Marcel
>>>
>>> Am 28.04.2022 00:39:12 schrieb Juan Vuletich <juanvuletich at zoho.com>:
>>>
>>> Hi Folks,
>>>
>>> I just discovered that the recent 202204190959 Mac VM includes Tobias
>>> HiDpi support on the Mac. This is very good news indeed, but It is not
>>> exactly what most users would prefer.
>>>
>>> On a Retina MacBook, you can set an apparent display resolution (System
>>> Preferences.../ Displays). By default, my 2019 15" MBP suggest half
>>> "real" resolution ("Looks like 1440x900" when LCD is 2880x1800). In 
>>> this
>>> case, the new VM offers the true native resolution to Cuis / Squeak. 
>>> So,
>>> in this case, it works perfectly well, and everything looks really 
>>> great.
>>>
>>> The problem is that MacOs supports several other apparent resolutions.
>>> Many people, me included, prefer "Looks like 1680x1050" or "Looks like
>>> 1920x1200") to have more room for other Mac apps. But in these cases,
>>> the VM doesn't offer the LCD native resolution to Cuis / Squeak 
>>> anymore.
>>> It offers twice the apparent resolution, i.e. 3360x2100 or 3840x2400.
>>> Then MacOs scales this higher virtual resolution to the actual
>>> 2880x1800, but it generates visual artifacts and a decrease in visual
>>> quality.
>>>
>>> For my own private use, the solution is to use the EasyRes application,
>>> and set the display to the true 2880x1800 resolution. When I do this,
>>> Cuis gets the corrrect Display size both with previous and newer VMs.
>>>
>>> But it would be great if there was a way for other Cuis / Squeak users
>>> to get their true Display resolution by default, and without needing to
>>> change OS settings each time they start their favorite Smalltalk.
>>>
>>> Thanks,
>>>
>>> -- 
>>> Juan Vuletich
>>> www.cuis-smalltalk.org
>>> https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev
>>> https://github.com/jvuletich
>>> https://www.linkedin.com/in/juan-vuletich-75611b3
>>> https://independent.academia.edu/JuanVuletich
>>> https://www.researchgate.net/profile/Juan-Vuletich
>>> https://patents.justia.com/inventor/juan-manuel-vuletich
>>> https://twitter.com/JuanVuletich
>>>


-- 
Juan Vuletich
www.cuis-smalltalk.org
https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev
https://github.com/jvuletich
https://www.linkedin.com/in/juan-vuletich-75611b3
https://independent.academia.edu/JuanVuletich
https://www.researchgate.net/profile/Juan-Vuletich
https://patents.justia.com/inventor/juan-manuel-vuletich
https://twitter.com/JuanVuletich

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20220428/42110184/attachment-0001.html>