Hi Tobias,

> On Oct 8, 2020, at 1:12 AM, Tobias Pape <Das.Linux at gmx.de> wrote:
> 
> Hi
> 
> Sorry, I did not see this mail.
> 
>>> On 01.10.2020, at 14:44, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>> Hi Tobias,
>>>> On Sep 30, 2020, at 1:11 PM, Tobias Pape <Das.Linux at gmx.de> wrote:
>>> 
>>>> On 30.09.2020, at 19:24, Thiede, Christoph <Christoph.Thiede at student.hpi.uni-potsdam.de> wrote:
>>>> On Windows, it appears to be a democratic thing - the majority of pixels wins in the question of DPI value. But I'm not absolutely sure about this and cannot test this right now. I don't believe it would be a good idea to override this behavior, even if we could ...
>>> Yes.
>>> Although I made it modifyable on Unix, just out of tradition that unix leaks every screw…
>>> (https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/krono/highdpi-v2/platforms/unix/vm-display-X11/sqUnixX11Scale.c#L182)
>>> So, anyone interested in me putting the VM stuff into the main branch?
>> Yes.  The only issue is backwards compatibility.  If it isn’t backwards compatible it’s time to
>> a) do a new release of the 5.x vm
>> b) bump the version number of the highdpi vm to 6.x
> 
> It's backward compatible in the sense that nothing really breaks, but things are _tiny_ on HighDPI displays and the image might not care.
> 
> The best way would be a "handshake" between image and VM, akin to:
> 
> - start
> - image says: please do high-dpi
> - vm says: can do, here you are.
> 
> The problem ist that this handshake comes too late.
> For OSX, the canvas has to be set up early on and cannot really be changed without grabbing too deep in the guts of the (now three variants of) display handling code.
> Windows might be similar.
> 
> so there are these quadrants:
> 
> x          | old VM  | new VM 
> -----------+---------+--------
>          |         |
> old Image  |  OK     | Problem
>          |         |
> -----------+---------+--------
>          |         |
> new Image  |  OK*    |  OK
>          |         |
> 
> *The high-dpi code just works fine with a constant scale factor, no probs.
> 
> If someone has an Idea except for "roll with it", I'm all ears.

The solution for these kinds of issues is to add a bit to the image header flags that says whether the image is high dpi aware.  The vm tests this bit immediately after loading the image.
- Old images do not have the bit set so the vm does not enable high dpi.
- there is an accessor (Smalltalk vmParameterAt: 48 [put:]) that can be used to set the bit from the image.
- we can provide a command-line argument to enable (and maybe even countermand the set bit in the image header) high dpi.

It takes me a few minutes to add one of these flags.  Here’s the existing set:

48    various properties of the Cog image as an integer encoding an array of bit flags.
             Bit 0: tells the VM that the image's Process class has threadId as its 5th inst var (after nextLink, suspendedContext, priority & myList)
             Bit 1: on Cog JIT VMs asks the VM to set the flag bit in interpreted methods
             Bit 2: if set, preempting a process puts it to the head of its run queue, not the back,
                     i.e. preempting a process by a higher priority one will not cause the preempted process to yield
                         to others at the same priority.
             Bit 3: in a muilt-threaded VM, if set, the Window system will only be accessed from the first VM thread
             Bit 4: in a Spur vm, if set, causes weaklings and ephemerons to be queued individually for finalization
             Bit 5: if set, implies wheel events will be delivered as such and not mapped to arrow key events
             Bit 6: if set, implies arithmetic primitives will fail if given arguments of different types (float vs int)


>> If it is backwards compatible then what are you waiting for?
>> If you already did, and that’s why yesterday my Squeak desktop suddenly looked so crisp, then thank you sooo sooo much, if looks *fantastic*!!
> 
> Hm, i only have the stuff on the branch, there must be some magic going on ;D

Yes, I think I had a fantasy :-)

> Best regards
>   -Tobias

Cheers,
_,,,^..^,,,_ (phone)