Smalltalk › Squeak › Squeak - Dev

highdpi testing

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

19 messages Options

Tobias Pape

highdpi testing

Hi all

I have fiddled with the highdpi stuff and managed Linux/Unix to join the party.

If you're interested, have a look at
https://github.com/OpenSmalltalk/opensmalltalk-vm/tree/krono/highdpi-v2

The main thing that changes is that primitiveScreenScaleFactor now can dynamically determine what
scale to use for a monitor. Per se, that does nothing, but the DpiAware -Changeset below allows
Morphic and graphics to react to that.

This should work on
- OSX (CoreGraphics, OpenGL, Metal)
- Windows
- Linux (X11, fbdev)

I think this might be especially interesting for Tony and Christoph, among others.

Things to Note:
- Windows needs a manifest. This can be tricky. See
https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/krono/highdpi-v2/scripts/ci/travis_build.sh#L21
https://github.com/OpenSmalltalk/opensmalltalk-vm/compare/Cog...krono/highdpi-v2#diff-f0c6c15289ff7521735d7e74a350903dL15
- Mac needs a customized Info.plist
https://github.com/OpenSmalltalk/opensmalltalk-vm/compare/Cog...krono/highdpi-v2#diff-9bc015b0fdf6b3aa927c5e49b2d882b9R129
- Linux can be a mess.
There are now a few Environment variables to help out:
https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/a2690b1b4e5c4488c716613f6654a74e31fa018a/platforms/unix/vm/sqUnixDisplayHelpers.h
Multimonitor people might want to set
SQUEAK_DISPLAY_PER_MONITOR_SCALE=1
Tony on the Phone might want to set
SQUEAK_DISPLAY_PREFER_PHYSICAL_SCALE=1

Have fun and play around :)

Best regards
-Tobias

DpiAware.1.cs (20K) Download Attachment

DisplayScreen class-actualScreenScaleFactor.st (325 bytes) Download Attachment

Craig Latta

Re: highdpi testing

Hooray! Thanks, Tobias!

-C

***

On 17/9/20 08:20, Tobias Pape wrote:

> Hi all
>
> I have fiddled with the highdpi stuff and managed Linux/Unix to join
the party.
>
> If you're interested, have a look at
> https://github.com/OpenSmalltalk/opensmalltalk-vm/tree/krono/highdpi-v2
>
>
> The main thing that changes is that primitiveScreenScaleFactor now can
dynamically determine what
> scale to use for a monitor. Per se, that does nothing, but the
DpiAware -Changeset below allows
> Morphic and graphics to react to that.
>
> This should work on
> - OSX (CoreGraphics, OpenGL, Metal)
> - Windows
> - Linux (X11, fbdev)
>
> I think this might be especially interesting for Tony and Christoph,
among others.
>
> Things to Note:
> - Windows needs a manifest. This can be tricky. See
>
https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/krono/highdpi-v2/scripts/ci/travis_build.sh#L21
>
https://github.com/OpenSmalltalk/opensmalltalk-vm/compare/Cog...krono/highdpi-v2#diff-f0c6c15289ff7521735d7e74a350903dL15
> - Mac needs a customized Info.plist
>
https://github.com/OpenSmalltalk/opensmalltalk-vm/compare/Cog...krono/highdpi-v2#diff-9bc015b0fdf6b3aa927c5e49b2d882b9R129
> - Linux can be a mess.
> There are now a few Environment variables to help out:
>
https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/a2690b1b4e5c4488c716613f6654a74e31fa018a/platforms/unix/vm/sqUnixDisplayHelpers.h

> Multimonitor people might want to set
> SQUEAK_DISPLAY_PER_MONITOR_SCALE=1
> Tony on the Phone might want to set
> SQUEAK_DISPLAY_PREFER_PHYSICAL_SCALE=1
>
>
> Have fun and play around :)
>
> Best regards
> -Tobias

--
Craig Latta :: research computer scientist
Black Page Digital :: Berkeley, California
663137D7940BF5C0AFC 1349FB2ADA32C4D5314CE

Christoph Thiede

Re: highdpi testing

Hi Tobias,

this sounds very promising, but unfortunately, I cannot try it out yet. I checked out your branch and built the VM for Win32, but while loading your changeset, my image gets damaged because it does not understand #displayScaled. I used a fresh #19860 image. Am I missing any dependency? :-)

Best,

Christoph

Von: Squeak-dev <[hidden email]> im Auftrag von Craig Latta <[hidden email]>
Gesendet: Donnerstag, 17. September 2020 19:34:49
An: [hidden email]
Betreff: Re: [squeak-dev] highdpi testing

     Hooray! Thanks, Tobias!

-C

***

     On 17/9/20 08:20, Tobias Pape wrote:

> Hi all
>
> I have fiddled with the highdpi stuff and managed Linux/Unix to join
the party.
>
> If you're interested, have a look at
>        https://github.com/OpenSmalltalk/opensmalltalk-vm/tree/krono/highdpi-v2
>
>
> The main thing that changes is that primitiveScreenScaleFactor now can
dynamically determine what
> scale to use for a monitor. Per se, that does nothing, but the
DpiAware -Changeset below allows
> Morphic and graphics to react to that.
>
> This should work on
>        - OSX (CoreGraphics, OpenGL, Metal)
>        - Windows
>        - Linux (X11, fbdev)
>
> I think this might be especially interesting for Tony and Christoph,
among others.
>
> Things to Note:
> - Windows needs a manifest. This can be tricky. See
>
https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/krono/highdpi-v2/scripts/ci/travis_build.sh#L21
>
https://github.com/OpenSmalltalk/opensmalltalk-vm/compare/Cog...krono/highdpi-v2#diff-f0c6c15289ff7521735d7e74a350903dL15
> - Mac needs a customized Info.plist
>
https://github.com/OpenSmalltalk/opensmalltalk-vm/compare/Cog...krono/highdpi-v2#diff-9bc015b0fdf6b3aa927c5e49b2d882b9R129
> - Linux can be a mess.
>   There are now a few Environment variables to help out:
>
https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/a2690b1b4e5c4488c716613f6654a74e31fa018a/platforms/unix/vm/sqUnixDisplayHelpers.h
>   Multimonitor people might want to set
>        SQUEAK_DISPLAY_PER_MONITOR_SCALE=1
>   Tony on the Phone might want to set
>        SQUEAK_DISPLAY_PREFER_PHYSICAL_SCALE=1
>
>
> Have fun and play around :)
>
> Best regards
>        -Tobias

--
Craig Latta :: research computer scientist
Black Page Digital :: Berkeley, California
663137D7940BF5C0AFC 1349FB2ADA32C4D5314CE

Carpe Squeak!

Tobias Pape

Re: highdpi testing

> On 19.09.2020, at 15:28, Thiede, Christoph <[hidden email]> wrote:
>
> Hi Tobias,
>
> this sounds very promising, but unfortunately, I cannot try it out yet. I checked out your branch and built the VM for Win32, but while loading your changeset, my image gets damaged because it does not understand #displayScaled.

That is part of the Change set.
Which class misses that?

Also, one might have to reset all the UI themes.

-t

> I used a fresh #19860 image. Am I missing any dependency? :-)
>
> Best,
> Christoph
> Von: Squeak-dev <[hidden email]> im Auftrag von Craig Latta <[hidden email]>
> Gesendet: Donnerstag, 17. September 2020 19:34:49
> An: [hidden email]
> Betreff: Re: [squeak-dev] highdpi testing
>
>
> Hooray! Thanks, Tobias!
>
>
> -C
>
> ***
>
> On 17/9/20 08:20, Tobias Pape wrote:
>
> > Hi all
> >
> > I have fiddled with the highdpi stuff and managed Linux/Unix to join
> the party.
> >
> > If you're interested, have a look at
> > https://github.com/OpenSmalltalk/opensmalltalk-vm/tree/krono/highdpi-v2
> >
> >
> > The main thing that changes is that primitiveScreenScaleFactor now can
> dynamically determine what
> > scale to use for a monitor. Per se, that does nothing, but the
> DpiAware -Changeset below allows
> > Morphic and graphics to react to that.
> >
> > This should work on
> > - OSX (CoreGraphics, OpenGL, Metal)
> > - Windows
> > - Linux (X11, fbdev)
> >
> > I think this might be especially interesting for Tony and Christoph,
> among others.
> >
> > Things to Note:
> > - Windows needs a manifest. This can be tricky. See
> >
> https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/krono/highdpi-v2/scripts/ci/travis_build.sh#L21
> >
> https://github.com/OpenSmalltalk/opensmalltalk-vm/compare/Cog...krono/highdpi-v2#diff-f0c6c15289ff7521735d7e74a350903dL15
> > - Mac needs a customized Info.plist
> >
> https://github.com/OpenSmalltalk/opensmalltalk-vm/compare/Cog...krono/highdpi-v2#diff-9bc015b0fdf6b3aa927c5e49b2d882b9R129
> > - Linux can be a mess.
> > There are now a few Environment variables to help out:
> >
> https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/a2690b1b4e5c4488c716613f6654a74e31fa018a/platforms/unix/vm/sqUnixDisplayHelpers.h
> > Multimonitor people might want to set
> > SQUEAK_DISPLAY_PER_MONITOR_SCALE=1
> > Tony on the Phone might want to set
> > SQUEAK_DISPLAY_PREFER_PHYSICAL_SCALE=1
> >
> >
> > Have fun and play around :)
> >
> > Best regards
> > -Tobias

Beckmann, Tom

Re: highdpi testing

DpiAware.1.cs (20K) Download Attachment

Christoph Thiede

Re: highdpi testing

Hi,

ah, I had assumed something like this, thanks for fixing, Tom! :-)

#actualScreenScaleFactor is a very helpful tool, but I do not yet see the whole idea of the changeset.

In what sense is this meant to be a complement of RealEstateAgent >> #scaleFactor or rather an orthogonal concept?

After loading the changeset and resetting my UI theme, the background image of the world disappeared and all new windows are huge, but they still have a tiny font - am I supposed to set the #scaleFactor manually (to 12, in my example)?

Where exactly can I see any components in the image that are upscaled by the new changeset?

Best,

Christoph

Von: Squeak-dev <[hidden email]> im Auftrag von Beckmann, Tom
Gesendet: Samstag, 19. September 2020 16:03:58
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] highdpi testing

Hi,

turns out, we try drawing things while we load things :)

In the attached, updated changeset I moved the #displayScaled definitions first so that we can happily resume drawing. Also, I removed the usage of the deprecated #anyOpenWindowLikeMe, which caused my image to freeze.

Best,
Tom
________________________________________
From: Squeak-dev <[hidden email]> on behalf of Tobias Pape <[hidden email]>
Sent: Saturday, September 19, 2020 3:54:06 PM
To: The general-purpose Squeak developers list
Subject: Re: [squeak-dev] highdpi testing

> On 19.09.2020, at 15:28, Thiede, Christoph <[hidden email]> wrote:
>
> Hi Tobias,
>
> this sounds very promising, but unfortunately, I cannot try it out yet. I checked out your branch and built the VM for Win32, but while loading your changeset, my image gets damaged because it does not understand #displayScaled.

That is part of the Change set.
Which class misses that?

Also, one might have to reset all the UI themes.

-t

> I used a fresh #19860 image. Am I missing any dependency? :-)
>
> Best,
> Christoph
> Von: Squeak-dev <[hidden email]> im Auftrag von Craig Latta <[hidden email]>
> Gesendet: Donnerstag, 17. September 2020 19:34:49
> An: [hidden email]
> Betreff: Re: [squeak-dev] highdpi testing
>
>
>      Hooray! Thanks, Tobias!
>
>
> -C
>
> ***
>
>      On 17/9/20 08:20, Tobias Pape wrote:
>
> > Hi all
> >
> > I have fiddled with the highdpi stuff and managed Linux/Unix to join
> the party.
> >
> > If you're interested, have a look at
> >        https://github.com/OpenSmalltalk/opensmalltalk-vm/tree/krono/highdpi-v2
> >
> >
> > The main thing that changes is that primitiveScreenScaleFactor now can
> dynamically determine what
> > scale to use for a monitor. Per se, that does nothing, but the
> DpiAware -Changeset below allows
> > Morphic and graphics to react to that.
> >
> > This should work on
> >        - OSX (CoreGraphics, OpenGL, Metal)
> >        - Windows
> >        - Linux (X11, fbdev)
> >
> > I think this might be especially interesting for Tony and Christoph,
> among others.
> >
> > Things to Note:
> > - Windows needs a manifest. This can be tricky. See
> >
> https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/krono/highdpi-v2/scripts/ci/travis_build.sh#L21
> >
> https://github.com/OpenSmalltalk/opensmalltalk-vm/compare/Cog...krono/highdpi-v2#diff-f0c6c15289ff7521735d7e74a350903dL15
> > - Mac needs a customized Info.plist
> >
> https://github.com/OpenSmalltalk/opensmalltalk-vm/compare/Cog...krono/highdpi-v2#diff-9bc015b0fdf6b3aa927c5e49b2d882b9R129
> > - Linux can be a mess.
> >   There are now a few Environment variables to help out:
> >
> https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/a2690b1b4e5c4488c716613f6654a74e31fa018a/platforms/unix/vm/sqUnixDisplayHelpers.h
> >   Multimonitor people might want to set
> >        SQUEAK_DISPLAY_PER_MONITOR_SCALE=1
> >   Tony on the Phone might want to set
> >        SQUEAK_DISPLAY_PREFER_PHYSICAL_SCALE=1
> >
> >
> > Have fun and play around :)
> >
> > Best regards
> >        -Tobias

Carpe Squeak!

Tobias Pape

Re: highdpi testing

> On 19.09.2020, at 19:26, Thiede, Christoph <[hidden email]> wrote:
>
> Hi,
>
> ah, I had assumed something like this, thanks for fixing, Tom! :-)
>
> #actualScreenScaleFactor is a very helpful tool, but I do not yet see the whole idea of the changeset.
> In what sense is this meant to be a complement of RealEstateAgent >> #scaleFactor or rather an orthogonal concept?
> After loading the changeset and resetting my UI theme, the background image of the world disappeared and all new windows are huge, but they still have a tiny font - am I supposed to set the #scaleFactor manually (to 12, in my example)?
> Where exactly can I see any components in the image that are upscaled by the new changeset?
>

These do something.
Load in order:

DpiAware-Kernel
DpiAware-Morpic
DpiAware-Display

First two are harmless, third will do something.
If nothing changes, do
UserInterfaceTheme cleanUpAndReset.

Issues ensue.
- Layouting borks.
The assert after the potential relayout
self assert: (self hasProperty: #doLayoutAgain) not
fails already in the docking bar…
- Fonts with UI-Themes do not work.
These are "Deep-referenced" to a pixel size (for Strike fonts) on creation, (so also during UserInterfaceTheme cleanUpAndReset).
However, when the scale factor changes, the pixel-sized fonts don't match the point sizes anymore…
This used to work pre-UI-Themes, as everyone requesting a Font did so by directly asking StrikeFont or TextStyle at the time the
Font was used. Hummm..

Hope you enjoy.
-t

DpiAware-Display.1.cs (1K) Download Attachment

DpiAware-Kernel.1.cs (5K) Download Attachment

DpiAware-Morphic.1.cs (7K) Download Attachment

Christoph Thiede

Re: highdpi testing

Hi Tobias,

sorry I did not answer earlier! This approach looks better for me, however, the wheel is still not absolutely round:

(The shadows have a wrong position.)

For the first step, we could start by asking the user whether they would like to change the font size (#changeFontSize:) when a new scale factor is detected, couldn't we?

PS: @Tom:

> we try drawing things while we load things :)

For the case you did not already read it, I created a changeset that could solve this problem: http://forum.world.st/Changeset-Eliminating-global-state-from-Morphic-tp5121690p5122464.html It also allow me to file in the original DpiAware changeset.

Best,

Christoph

Von: Squeak-dev <[hidden email]> im Auftrag von Tobias Pape <[hidden email]>
Gesendet: Montag, 21. September 2020 15:50:30
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] highdpi testing

Hi

> On 19.09.2020, at 19:26, Thiede, Christoph <[hidden email]> wrote:
>
> Hi,
>
> ah, I had assumed something like this, thanks for fixing, Tom! :-)
>
> #actualScreenScaleFactor is a very helpful tool, but I do not yet see the whole idea of the changeset.
> In what sense is this meant to be a complement of RealEstateAgent >> #scaleFactor or rather an orthogonal concept?
> After loading the changeset and resetting my UI theme, the background image of the world disappeared and all new windows are huge, but they still have a tiny font - am I supposed to set the #scaleFactor manually (to 12, in my example)?
> Where exactly can I see any components in the image that are upscaled by the new changeset?
>

These do something.
Load in order:

DpiAware-Kernel
DpiAware-Morpic
DpiAware-Display

First two are harmless, third will do something.
If nothing changes, do
        UserInterfaceTheme cleanUpAndReset.

Issues ensue.
- Layouting borks.
        The assert after the potential relayout
                self assert: (self hasProperty: #doLayoutAgain) not
        fails already in the docking bar…
- Fonts with UI-Themes do not work.
These are "Deep-referenced" to a pixel size (for Strike fonts) on creation, (so also during UserInterfaceTheme cleanUpAndReset).
However, when the scale factor changes, the pixel-sized fonts don't match the point sizes anymore…
    This used to work pre-UI-Themes, as everyone requesting a Font did so by directly asking StrikeFont or TextStyle at the time the
Font was used. Hummm..

Hope you enjoy.
-t

Carpe Squeak!

Tobias Pape

Re: highdpi testing

>
> PS: @Tom:
> > we try drawing things while we load things :)
> For the case you did not already read it, I created a changeset that could solve this problem: http://forum.world.st/Changeset-Eliminating-global-state-from-Morphic-tp5121690p5122464.html It also allow me to file in the original DpiAware changeset.
>
> Best,
> Christoph
> Von: Squeak-dev <[hidden email]> im Auftrag von Tobias Pape <[hidden email]>
> Gesendet: Montag, 21. September 2020 15:50:30
> An: The general-purpose Squeak developers list
> Betreff: Re: [squeak-dev] highdpi testing
>
> Hi
>
> > On 19.09.2020, at 19:26, Thiede, Christoph <[hidden email]> wrote:
> >
> > Hi,
> >
> > ah, I had assumed something like this, thanks for fixing, Tom! :-)
> >
> > #actualScreenScaleFactor is a very helpful tool, but I do not yet see the whole idea of the changeset.
> > In what sense is this meant to be a complement of RealEstateAgent >> #scaleFactor or rather an orthogonal concept?
> > After loading the changeset and resetting my UI theme, the background image of the world disappeared and all new windows are huge, but they still have a tiny font - am I supposed to set the #scaleFactor manually (to 12, in my example)?
> > Where exactly can I see any components in the image that are upscaled by the new changeset?
> >
>
> These do something.
> Load in order:
>
> DpiAware-Kernel
> DpiAware-Morpic
> DpiAware-Display
>
> First two are harmless, third will do something.
> If nothing changes, do
> UserInterfaceTheme cleanUpAndReset.
>
> Issues ensue.
> - Layouting borks.
> The assert after the potential relayout
> self assert: (self hasProperty: #doLayoutAgain) not
> fails already in the docking bar…
> - Fonts with UI-Themes do not work.
> These are "Deep-referenced" to a pixel size (for Strike fonts) on creation, (so also during UserInterfaceTheme cleanUpAndReset).
> However, when the scale factor changes, the pixel-sized fonts don't match the point sizes anymore…
> This used to work pre-UI-Themes, as everyone requesting a Font did so by directly asking StrikeFont or TextStyle at the time the
> Font was used. Hummm..
>
> Hope you enjoy.
> -t

Christoph Thiede

Re: highdpi testing

Hi Tobias,

> > For the first step, we could start by asking the user whether they would like to change the font size (#changeFontSize:) when a new scale factor is detected, couldn't we?

> No, that ought to be automatic;

Personally, I'd prefer a preference for this. ;-) My Windows system often changes its DPI value multiple times a day and #changeFontSize: has a big impact on your image as it replaces the UI theme (for example, all windows are resized and repositioned, custom theme adjustments are lost, the search bar is emptied, and the history of workspaces is cleared). Also, it's an expensive operation that can slow my system down for ca. 10 seconds per open image. I would only change the font size if I need it just at the moment (I always use to keep open several images even if I do not use all of them frequently).

Best,

Christoph

Von: Squeak-dev <[hidden email]> im Auftrag von Tobias Pape <[hidden email]>
Gesendet: Dienstag, 29. September 2020 10:28:01
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] highdpi testing

Hi
> On 25.09.2020, at 21:43, Thiede, Christoph <[hidden email]> wrote:
>
> Hi Tobias,
>
> sorry I did not answer earlier! This approach looks better for me, however, the wheel is still not absolutely round:
>
>
> (The shadows have a wrong position.)

I know, I had a patch that worked in 2016, but things changed and I hand't had the time yet.

>
> For the first step, we could start by asking the user whether they would like to change the font size (#changeFontSize:) when a new scale factor is detected, couldn't we?

No, that ought to be automatic;

-t

>
> PS: @Tom:
> > we try drawing things while we load things :)
> For the case you did not already read it, I created a changeset that could solve this problem: http://forum.world.st/Changeset-Eliminating-global-state-from-Morphic-tp5121690p5122464.html It also allow me to file in the original DpiAware changeset.
>
> Best,
> Christoph
> Von: Squeak-dev <[hidden email]> im Auftrag von Tobias Pape <[hidden email]>
> Gesendet: Montag, 21. September 2020 15:50:30
> An: The general-purpose Squeak developers list
> Betreff: Re: [squeak-dev] highdpi testing
>
> Hi
>
> > On 19.09.2020, at 19:26, Thiede, Christoph <[hidden email]> wrote:
> >
> > Hi,
> >
> > ah, I had assumed something like this, thanks for fixing, Tom! :-)
> >
> > #actualScreenScaleFactor is a very helpful tool, but I do not yet see the whole idea of the changeset.
> > In what sense is this meant to be a complement of RealEstateAgent >> #scaleFactor or rather an orthogonal concept?
> > After loading the changeset and resetting my UI theme, the background image of the world disappeared and all new windows are huge, but they still have a tiny font - am I supposed to set the #scaleFactor manually (to 12, in my example)?
> > Where exactly can I see any components in the image that are upscaled by the new changeset?
> >
>
> These do something.
> Load in order:
>
> DpiAware-Kernel
> DpiAware-Morpic
> DpiAware-Display
>
> First two are harmless, third will do something.
> If nothing changes, do
>         UserInterfaceTheme cleanUpAndReset.
>
> Issues ensue.
> - Layouting borks.
>         The assert after the potential relayout
>                 self assert: (self hasProperty: #doLayoutAgain) not
>         fails already in the docking bar…
> - Fonts with UI-Themes do not work.
>   These are "Deep-referenced" to a pixel size (for Strike fonts) on creation, (so also during UserInterfaceTheme cleanUpAndReset).
>   However, when the scale factor changes, the pixel-sized fonts don't match the point sizes anymore…
>     This used to work pre-UI-Themes, as everyone requesting a Font did so by directly asking StrikeFont or TextStyle at the time the
>   Font was used. Hummm..
>
> Hope you enjoy.
> -t

Carpe Squeak!

marcel.taeumel

Re: highdpi testing

> Personally, I'd prefer a preference for this.

You would only need a preference or confirmation dialog if we fail to implement it correctly. ;-) The goal would be that your content does not get messed up when detecting a DPI change.

Best,

Marcel

Am 30.09.2020 12:21:37 schrieb Thiede, Christoph <[hidden email]>:

Hi Tobias,

> > For the first step, we could start by asking the user whether they would like to change the font size (#changeFontSize:) when a new scale factor is detected, couldn't we?

>

> No, that ought to be automatic;

Personally, I'd prefer a preference for this. ;-) My Windows system often changes its DPI value multiple times a day and #changeFontSize: has a big impact on your image as it replaces the UI theme (for example, all windows are resized and repositioned, custom theme adjustments are lost, the search bar is emptied, and the history of workspaces is cleared). Also, it's an expensive operation that can slow my system down for ca. 10 seconds per open image. I would only change the font size if I need it just at the moment (I always use to keep open several images even if I do not use all of them frequently).

Best,

Christoph

Von: Squeak-dev <[hidden email]> im Auftrag von Tobias Pape <[hidden email]>
Gesendet: Dienstag, 29. September 2020 10:28:01
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] highdpi testing

Hi
> On 25.09.2020, at 21:43, Thiede, Christoph <[hidden email]> wrote:
>
> Hi Tobias,
>
> sorry I did not answer earlier! This approach looks better for me, however, the wheel is still not absolutely round:
>
>
> (The shadows have a wrong position.)

I know, I had a patch that worked in 2016, but things changed and I hand't had the time yet.

>
> For the first step, we could start by asking the user whether they would like to change the font size (#changeFontSize:) when a new scale factor is detected, couldn't we?

No, that ought to be automatic;

-t

>
> PS: @Tom:
> > we try drawing things while we load things :)
> For the case you did not already read it, I created a changeset that could solve this problem: http://forum.world.st/Changeset-Eliminating-global-state-from-Morphic-tp5121690p5122464.html It also allow me to file in the original DpiAware changeset.
>
> Best,
> Christoph
> Von: Squeak-dev <[hidden email]> im Auftrag von Tobias Pape <[hidden email]>
> Gesendet: Montag, 21. September 2020 15:50:30
> An: The general-purpose Squeak developers list
> Betreff: Re: [squeak-dev] highdpi testing
>
> Hi
>
> > On 19.09.2020, at 19:26, Thiede, Christoph <[hidden email]> wrote:
> >
> > Hi,
> >
> > ah, I had assumed something like this, thanks for fixing, Tom! :-)
> >
> > #actualScreenScaleFactor is a very helpful tool, but I do not yet see the whole idea of the changeset.
> > In what sense is this meant to be a complement of RealEstateAgent >> #scaleFactor or rather an orthogonal concept?
> > After loading the changeset and resetting my UI theme, the background image of the world disappeared and all new windows are huge, but they still have a tiny font - am I supposed to set the #scaleFactor manually (to 12, in my example)?
> > Where exactly can I see any components in the image that are upscaled by the new changeset?
> >
>
> These do something.
> Load in order:
>
> DpiAware-Kernel
> DpiAware-Morpic
> DpiAware-Display
>
> First two are harmless, third will do something.
> If nothing changes, do
>         UserInterfaceTheme cleanUpAndReset.
>
> Issues ensue.
> - Layouting borks.
>         The assert after the potential relayout
>                 self assert: (self hasProperty: #doLayoutAgain) not
>         fails already in the docking bar…
> - Fonts with UI-Themes do not work.
>   These are "Deep-referenced" to a pixel size (for Strike fonts) on creation, (so also during UserInterfaceTheme cleanUpAndReset).
>   However, when the scale factor changes, the pixel-sized fonts don't match the point sizes anymore…
>     This used to work pre-UI-Themes, as everyone requesting a Font did so by directly asking StrikeFont or TextStyle at the time the
>   Font was used. Hummm..
>
> Hope you enjoy.
> -t

timrowledge

Re: highdpi testing

In reply to this post by Christoph Thiede

A strange and possibly relevant though crossed my mind as I read that email - what happens with windows that cross physical display boundaries where the displays have different dpi values?

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Useful random insult:- His spirit guide is a three-toed sloth.

Christoph Thiede

Re: highdpi testing

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 ...

Best,

Christoph

Von: Squeak-dev <[hidden email]> im Auftrag von tim Rowledge <[hidden email]>
Gesendet: Mittwoch, 30. September 2020 19:20:45
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] highdpi testing

Carpe Squeak!

Tobias Pape

Re: highdpi testing

In reply to this post by timrowledge

> On 30.09.2020, at 19:20, tim Rowledge <[hidden email]> wrote:
>
> A strange and possibly relevant though crossed my mind as I read that email - what happens with windows that cross physical display boundaries where the displays have different dpi values?

That is exactly what I wrapped my brain around.
On the VM-Side, Windows and Mac do the sane thing reporting a different scale factor when the majority of window estate is on a new display.
I tried emulating that in the X/Unix implementation.

On the Image side, the scale factor is checked at the same time as the display size, and if it changes, a callback is triggered to update everything interested, such as fonts or morphs.

Best regards
-Tobias

Tobias Pape

Re: highdpi testing

In reply to this post by Christoph Thiede

> On 30.09.2020, at 19:24, Thiede, Christoph <[hidden email]> 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?

-t

Christoph Thiede

Re: highdpi testing

> So, anyone interested in me putting the VM stuff into the main branch?

+1! :-)

Best,

Christoph

Von: Squeak-dev <[hidden email]> im Auftrag von Tobias Pape <[hidden email]>
Gesendet: Mittwoch, 30. September 2020 22:10:56
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] highdpi testing

Carpe Squeak!

Eliot Miranda-2

Re: highdpi testing

In reply to this post by Tobias Pape

Hi Tobias,

> On Sep 30, 2020, at 1:11 PM, Tobias Pape <[hidden email]> wrote:
>
>
>> On 30.09.2020, at 19:24, Thiede, Christoph <[hidden email]> 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

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*!!

> -t
>

Tobias Pape

Re: highdpi testing

Hi

Sorry, I did not see this mail.

> On 01.10.2020, at 14:44, Eliot Miranda <[hidden email]> wrote:
>
> Hi Tobias,
>
>
>> On Sep 30, 2020, at 1:11 PM, Tobias Pape <[hidden email]> wrote:
>>
>>
>>> On 30.09.2020, at 19:24, Thiede, Christoph <[hidden email]> 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.

>
> 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

Best regards
-Tobias

Eliot Miranda-2

Re: highdpi testing

In reply to this post by Tobias Pape

Hi Tobias,

> On Oct 8, 2020, at 1:12 AM, Tobias Pape <[hidden email]> wrote:
>
> Hi
>
> Sorry, I did not see this mail.
>
>>> On 01.10.2020, at 14:44, Eliot Miranda <[hidden email]> wrote:
>> Hi Tobias,
>>>> On Sep 30, 2020, at 1:11 PM, Tobias Pape <[hidden email]> wrote:
>>>
>>>> On 30.09.2020, at 19:24, Thiede, Christoph <[hidden email]> 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)