I'm just trying the latest release VM (ARMv8 on a Pi in this case) and it seems to be doing Odd Things with the window size.
The same image on two different Pis opens with different window sizes. One Pi has a 1920@180 screen and the initial window is notably smaller than what it was when I saved the image, the other has a 1920@1440 screen and the initial window size is what I set. That size is not larger than the 1920@1080 screen, by the way. To the best of my recollection this is new (mis)behaviour.
We've always done some startup checks in the VM to fit the window within the available display limits but I don't remember previously over-riding the requested size this aggressively. Has anyone changed this code recently? Or is this a side effect of recent scale factor stuff? I can't spot any suspicious code in the image right now.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim A misplaced modifier walks into a bar owned a man with a glass eye named Ralph
Hi Tim --
Are you referring to the host-window size or the system-window size? I think you mean the latter. Whether or not the scale factor is involved, you can check by looking at what is selected in "Extras > Scale Factor" menu.
I am not sure that I really understand what you mean. However, there are two hard-coded numbers in RealEstateAgent class >> #strictlyStaggeredInitialFrameFor:... which we did not adjust to the scale factor.
... "Number to be staggered at each corner (less on small screens)" maxLevel := allowedArea area > 300000 ifTrue: [3] ifFalse: [2]. "Amount by which to stagger (less on small screens)" grid := allowedArea area > 500000 ifTrue: [40] ifFalse: [20]. ...
Would you apply a "* self scaleFactor" to those areas and see if the problem gets fixed? :-) Maybe also the grid.
---
This is most likely not a VM issue but related to a feature in newer VMs. It might be that a newer VM will actually deliver that platformScaleFactor which will then set the image-side uiScaleFactor which will then modify the "RealEstateAgent scaleFactor" which will then result in bigger default-window areas and thus hit those magic boundaries. Not sure.
Best, Marcel Am 29.05.2022 20:54:38 schrieb tim Rowledge tim@rowledge.org: I'm just trying the latest release VM (ARMv8 on a Pi in this case) and it seems to be doing Odd Things with the window size.
The same image on two different Pis opens with different window sizes. One Pi has a 1920@180 screen and the initial window is notably smaller than what it was when I saved the image, the other has a 1920@1440 screen and the initial window size is what I set. That size is not larger than the 1920@1080 screen, by the way. To the best of my recollection this is new (mis)behaviour.
We've always done some startup checks in the VM to fit the window within the available display limits but I don't remember previously over-riding the requested size this aggressively. Has anyone changed this code recently? Or is this a side effect of recent scale factor stuff? I can't spot any suspicious code in the image right now.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim A misplaced modifier walks into a bar owned a man with a glass eye named Ralph
Sorry if I wasn't clear - it's the *host* window size that is messed up for me.
On 2022-05-30, at 2:40 AM, Marcel Taeumel marcel.taeumel@hpi.de wrote:
Hi Tim --
Are you referring to the host-window size or the system-window size? I think you mean the latter. Whether or not the scale factor is involved, you can check by looking at what is selected in "Extras > Scale Factor" menu.
I am not sure that I really understand what you mean. However, there are two hard-coded numbers in RealEstateAgent class >> #strictlyStaggeredInitialFrameFor:... which we did not adjust to the scale factor.
... "Number to be staggered at each corner (less on small screens)" maxLevel := allowedArea area > 300000 ifTrue: [3] ifFalse: [2]. "Amount by which to stagger (less on small screens)" grid := allowedArea area > 500000 ifTrue: [40] ifFalse: [20]. ...
Would you apply a "* self scaleFactor" to those areas and see if the problem gets fixed? :-) Maybe also the grid.
This is most likely not a VM issue but related to a feature in newer VMs. It might be that a newer VM will actually deliver that platformScaleFactor which will then set the image-side uiScaleFactor which will then modify the "RealEstateAgent scaleFactor" which will then result in bigger default-window areas and thus hit those magic boundaries. Not sure.
Best, Marcel
Am 29.05.2022 20:54:38 schrieb tim Rowledge tim@rowledge.org:
I'm just trying the latest release VM (ARMv8 on a Pi in this case) and it seems to be doing Odd Things with the window size.
The same image on two different Pis opens with different window sizes. One Pi has a 1920@180 screen and the initial window is notably smaller than what it was when I saved the image, the other has a 1920@1440 screen and the initial window size is what I set. That size is not larger than the 1920@1080 screen, by the way. To the best of my recollection this is new (mis)behaviour.
We've always done some startup checks in the VM to fit the window within the available display limits but I don't remember previously over-riding the requested size this aggressively. Has anyone changed this code recently? Or is this a side effect of recent scale factor stuff? I can't spot any suspicious code in the image right now.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim A misplaced modifier walks into a bar owned a man with a glass eye named Ralph
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- Always responds to "Make Money Fast" postings on the Net.
Okay. Let my try to understand what is happening here.
Platform: LinuxARMv8
1. Resize window to ??? then save-and-quit. 2. Open on a 1920 by 1080 screen but window is smaller than ???. 3. Open on a 1920 by 1440 screen and window is exactly ???.
So, what is ??? in this scenario? :-)
And what are the results of...
Display platformScaleFactor. Display uiScaleFactor.
Best, Marcel Am 30.05.2022 19:02:24 schrieb tim Rowledge tim@rowledge.org: Sorry if I wasn't clear - it's the *host* window size that is messed up for me.
On 2022-05-30, at 2:40 AM, Marcel Taeumel wrote:
Hi Tim --
Are you referring to the host-window size or the system-window size? I think you mean the latter. Whether or not the scale factor is involved, you can check by looking at what is selected in "Extras > Scale Factor" menu.
I am not sure that I really understand what you mean. However, there are two hard-coded numbers in RealEstateAgent class >> #strictlyStaggeredInitialFrameFor:... which we did not adjust to the scale factor.
... "Number to be staggered at each corner (less on small screens)" maxLevel := allowedArea area > 300000 ifTrue: [3] ifFalse: [2]. "Amount by which to stagger (less on small screens)" grid := allowedArea area > 500000 ifTrue: [40] ifFalse: [20]. ...
Would you apply a "* self scaleFactor" to those areas and see if the problem gets fixed? :-) Maybe also the grid.
This is most likely not a VM issue but related to a feature in newer VMs. It might be that a newer VM will actually deliver that platformScaleFactor which will then set the image-side uiScaleFactor which will then modify the "RealEstateAgent scaleFactor" which will then result in bigger default-window areas and thus hit those magic boundaries. Not sure.
Best, Marcel
Am 29.05.2022 20:54:38 schrieb tim Rowledge :
I'm just trying the latest release VM (ARMv8 on a Pi in this case) and it seems to be doing Odd Things with the window size.
The same image on two different Pis opens with different window sizes. One Pi has a 1920@180 screen and the initial window is notably smaller than what it was when I saved the image, the other has a 1920@1440 screen and the initial window size is what I set. That size is not larger than the 1920@1080 screen, by the way. To the best of my recollection this is new (mis)behaviour.
We've always done some startup checks in the VM to fit the window within the available display limits but I don't remember previously over-riding the requested size this aggressively. Has anyone changed this code recently? Or is this a side effect of recent scale factor stuff? I can't spot any suspicious code in the image right now.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim A misplaced modifier walks into a bar owned a man with a glass eye named Ralph
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- Always responds to "Make Money Fast" postings on the Net.
Pi-4-1 screen size 1600@1200 VM /home/pi/Documents/Squeak/sqcogspur64ARMv8linuxht/lib/squeak/5.0-202205110711-64bit/squeak image squeak 6 alpha 21829 opens with display extent = 1016@702 increase to 1448@986 by usual dragging
save and quit
restart display extent is 1016@702.
Copy this file to Goldskin (another Pi 4) screen size 1920@1440 VM /home/pi/Documents/Squeak/sqcogspur64ARMv8linuxht/lib/squeak/5.0-202205110711-64bit/squeak opens with display extent1448@986 drag to extent 1632@1092 save and quit reopen display extent is 1632@1092
copy *that* back to Pi-4-1 display extent ... 1016@702
On 2022-05-31, at 8:26 AM, Marcel Taeumel marcel.taeumel@hpi.de wrote:
Okay. Let my try to understand what is happening here.
Platform: LinuxARMv8
- Resize window to ??? then save-and-quit.
- Open on a 1920 by 1080 screen but window is smaller than ???.
- Open on a 1920 by 1440 screen and window is exactly ???.
So, what is ??? in this scenario? :-)
And what are the results of...
Display platformScaleFactor. Display uiScaleFactor.
Best, Marcel
Am 30.05.2022 19:02:24 schrieb tim Rowledge tim@rowledge.org:
Sorry if I wasn't clear - it's the *host* window size that is messed up for me.
On 2022-05-30, at 2:40 AM, Marcel Taeumel wrote:
Hi Tim --
Are you referring to the host-window size or the system-window size? I think you mean the latter. Whether or not the scale factor is involved, you can check by looking at what is selected in "Extras > Scale Factor" menu.
I am not sure that I really understand what you mean. However, there are two hard-coded numbers in RealEstateAgent class >> #strictlyStaggeredInitialFrameFor:... which we did not adjust to the scale factor.
... "Number to be staggered at each corner (less on small screens)" maxLevel := allowedArea area > 300000 ifTrue: [3] ifFalse: [2]. "Amount by which to stagger (less on small screens)" grid := allowedArea area > 500000 ifTrue: [40] ifFalse: [20]. ...
Would you apply a "* self scaleFactor" to those areas and see if the problem gets fixed? :-) Maybe also the grid.
This is most likely not a VM issue but related to a feature in newer VMs. It might be that a newer VM will actually deliver that platformScaleFactor which will then set the image-side uiScaleFactor which will then modify the "RealEstateAgent scaleFactor" which will then result in bigger default-window areas and thus hit those magic boundaries. Not sure.
Best, Marcel
Am 29.05.2022 20:54:38 schrieb tim Rowledge :
I'm just trying the latest release VM (ARMv8 on a Pi in this case) and it seems to be doing Odd Things with the window size.
The same image on two different Pis opens with different window sizes. One Pi has a 1920@180 screen and the initial window is notably smaller than what it was when I saved the image, the other has a 1920@1440 screen and the initial window size is what I set. That size is not larger than the 1920@1080 screen, by the way. To the best of my recollection this is new (mis)behaviour.
We've always done some startup checks in the VM to fit the window within the available display limits but I don't remember previously over-riding the requested size this aggressively. Has anyone changed this code recently? Or is this a side effect of recent scale factor stuff? I can't spot any suspicious code in the image right now.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim A misplaced modifier walks into a bar owned a man with a glass eye named Ralph
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- Always responds to "Make Money Fast" postings on the Net.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: VMB: Verify, then Make Bad
Hi Tim --
Hmm... I cannot reproduce that in Ubuntu 18. What I can reproduce is a very strange behavior of primitiveHostWindowSizeSet in X11. I will look into that.
Best, Marcel Am 31.05.2022 19:07:53 schrieb tim Rowledge tim@rowledge.org: Pi-4-1 screen size 1600@1200 VM /home/pi/Documents/Squeak/sqcogspur64ARMv8linuxht/lib/squeak/5.0-202205110711-64bit/squeak image squeak 6 alpha 21829 opens with display extent = 1016@702 increase to 1448@986 by usual dragging
save and quit
restart display extent is 1016@702.
Copy this file to Goldskin (another Pi 4) screen size 1920@1440 VM /home/pi/Documents/Squeak/sqcogspur64ARMv8linuxht/lib/squeak/5.0-202205110711-64bit/squeak opens with display extent1448@986 drag to extent 1632@1092 save and quit reopen display extent is 1632@1092
copy *that* back to Pi-4-1 display extent ... 1016@702
On 2022-05-31, at 8:26 AM, Marcel Taeumel wrote:
Okay. Let my try to understand what is happening here.
Platform: LinuxARMv8
- Resize window to ??? then save-and-quit.
- Open on a 1920 by 1080 screen but window is smaller than ???.
- Open on a 1920 by 1440 screen and window is exactly ???.
So, what is ??? in this scenario? :-)
And what are the results of...
Display platformScaleFactor. Display uiScaleFactor.
Best, Marcel
Am 30.05.2022 19:02:24 schrieb tim Rowledge :
Sorry if I wasn't clear - it's the *host* window size that is messed up for me.
On 2022-05-30, at 2:40 AM, Marcel Taeumel wrote:
Hi Tim --
Are you referring to the host-window size or the system-window size? I think you mean the latter. Whether or not the scale factor is involved, you can check by looking at what is selected in "Extras > Scale Factor" menu.
I am not sure that I really understand what you mean. However, there are two hard-coded numbers in RealEstateAgent class >> #strictlyStaggeredInitialFrameFor:... which we did not adjust to the scale factor.
... "Number to be staggered at each corner (less on small screens)" maxLevel := allowedArea area > 300000 ifTrue: [3] ifFalse: [2]. "Amount by which to stagger (less on small screens)" grid := allowedArea area > 500000 ifTrue: [40] ifFalse: [20]. ...
Would you apply a "* self scaleFactor" to those areas and see if the problem gets fixed? :-) Maybe also the grid.
This is most likely not a VM issue but related to a feature in newer VMs. It might be that a newer VM will actually deliver that platformScaleFactor which will then set the image-side uiScaleFactor which will then modify the "RealEstateAgent scaleFactor" which will then result in bigger default-window areas and thus hit those magic boundaries. Not sure.
Best, Marcel
Am 29.05.2022 20:54:38 schrieb tim Rowledge :
I'm just trying the latest release VM (ARMv8 on a Pi in this case) and it seems to be doing Odd Things with the window size.
The same image on two different Pis opens with different window sizes. One Pi has a 1920@180 screen and the initial window is notably smaller than what it was when I saved the image, the other has a 1920@1440 screen and the initial window size is what I set. That size is not larger than the 1920@1080 screen, by the way. To the best of my recollection this is new (mis)behaviour.
We've always done some startup checks in the VM to fit the window within the available display limits but I don't remember previously over-riding the requested size this aggressively. Has anyone changed this code recently? Or is this a side effect of recent scale factor stuff? I can't spot any suspicious code in the image right now.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim A misplaced modifier walks into a bar owned a man with a glass eye named Ralph
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- Always responds to "Make Money Fast" postings on the Net.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: VMB: Verify, then Make Bad
Hi Tim --
See a quickfix via Graphics-mt.518.
Yet, we should take a more thorough look at what's going on here. Please report the following values for both settings:
Display platformScaleFactor. Display uiScaleFactor.
Best, Marcel Am 01.06.2022 11:19:37 schrieb Marcel Taeumel marcel.taeumel@hpi.de: Hi Tim --
Hmm... I cannot reproduce that in Ubuntu 18. What I can reproduce is a very strange behavior of primitiveHostWindowSizeSet in X11. I will look into that.
Best, Marcel Am 31.05.2022 19:07:53 schrieb tim Rowledge tim@rowledge.org: Pi-4-1 screen size 1600@1200 VM /home/pi/Documents/Squeak/sqcogspur64ARMv8linuxht/lib/squeak/5.0-202205110711-64bit/squeak image squeak 6 alpha 21829 opens with display extent = 1016@702 increase to 1448@986 by usual dragging
save and quit
restart display extent is 1016@702.
Copy this file to Goldskin (another Pi 4) screen size 1920@1440 VM /home/pi/Documents/Squeak/sqcogspur64ARMv8linuxht/lib/squeak/5.0-202205110711-64bit/squeak opens with display extent1448@986 drag to extent 1632@1092 save and quit reopen display extent is 1632@1092
copy *that* back to Pi-4-1 display extent ... 1016@702
On 2022-05-31, at 8:26 AM, Marcel Taeumel wrote:
Okay. Let my try to understand what is happening here.
Platform: LinuxARMv8
- Resize window to ??? then save-and-quit.
- Open on a 1920 by 1080 screen but window is smaller than ???.
- Open on a 1920 by 1440 screen and window is exactly ???.
So, what is ??? in this scenario? :-)
And what are the results of...
Display platformScaleFactor. Display uiScaleFactor.
Best, Marcel
Am 30.05.2022 19:02:24 schrieb tim Rowledge :
Sorry if I wasn't clear - it's the *host* window size that is messed up for me.
On 2022-05-30, at 2:40 AM, Marcel Taeumel wrote:
Hi Tim --
Are you referring to the host-window size or the system-window size? I think you mean the latter. Whether or not the scale factor is involved, you can check by looking at what is selected in "Extras > Scale Factor" menu.
I am not sure that I really understand what you mean. However, there are two hard-coded numbers in RealEstateAgent class >> #strictlyStaggeredInitialFrameFor:... which we did not adjust to the scale factor.
... "Number to be staggered at each corner (less on small screens)" maxLevel := allowedArea area > 300000 ifTrue: [3] ifFalse: [2]. "Amount by which to stagger (less on small screens)" grid := allowedArea area > 500000 ifTrue: [40] ifFalse: [20]. ...
Would you apply a "* self scaleFactor" to those areas and see if the problem gets fixed? :-) Maybe also the grid.
This is most likely not a VM issue but related to a feature in newer VMs. It might be that a newer VM will actually deliver that platformScaleFactor which will then set the image-side uiScaleFactor which will then modify the "RealEstateAgent scaleFactor" which will then result in bigger default-window areas and thus hit those magic boundaries. Not sure.
Best, Marcel
Am 29.05.2022 20:54:38 schrieb tim Rowledge :
I'm just trying the latest release VM (ARMv8 on a Pi in this case) and it seems to be doing Odd Things with the window size.
The same image on two different Pis opens with different window sizes. One Pi has a 1920@180 screen and the initial window is notably smaller than what it was when I saved the image, the other has a 1920@1440 screen and the initial window size is what I set. That size is not larger than the 1920@1080 screen, by the way. To the best of my recollection this is new (mis)behaviour.
We've always done some startup checks in the VM to fit the window within the available display limits but I don't remember previously over-riding the requested size this aggressively. Has anyone changed this code recently? Or is this a side effect of recent scale factor stuff? I can't spot any suspicious code in the image right now.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim A misplaced modifier walks into a bar owned a man with a glass eye named Ralph
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- Always responds to "Make Money Fast" postings on the Net.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: VMB: Verify, then Make Bad
With latest armv8 vm (https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/download/latest-b...) and updating my image it's the same situation.
The only new information is that I tried making the display window *smaller* and saving, and that reopens in the smaller size; so I have to assume that nothing has broken in the setting of the magic size-value in the image header, nor in the reading of that and trying to set the window size.
Also, using an older 5.3 clean image on this latest VM shows the same issue, so it isn't purely the image code
On 2022-06-01, at 2:19 AM, Marcel Taeumel marcel.taeumel@hpi.de wrote:
Hi Tim --
Hmm... I cannot reproduce that in Ubuntu 18. What I can reproduce is a very strange behavior of primitiveHostWindowSizeSet in X11. I will look into that.
Best, Marcel
Am 31.05.2022 19:07:53 schrieb tim Rowledge tim@rowledge.org:
Pi-4-1 screen size 1600@1200 VM /home/pi/Documents/Squeak/sqcogspur64ARMv8linuxht/lib/squeak/5.0-202205110711-64bit/squeak image squeak 6 alpha 21829 opens with display extent = 1016@702 increase to 1448@986 by usual dragging
save and quit
restart display extent is 1016@702.
Copy this file to Goldskin (another Pi 4) screen size 1920@1440 VM /home/pi/Documents/Squeak/sqcogspur64ARMv8linuxht/lib/squeak/5.0-202205110711-64bit/squeak opens with display extent1448@986 drag to extent 1632@1092 save and quit reopen display extent is 1632@1092
copy *that* back to Pi-4-1 display extent ... 1016@702
On 2022-05-31, at 8:26 AM, Marcel Taeumel wrote:
Okay. Let my try to understand what is happening here.
Platform: LinuxARMv8
- Resize window to ??? then save-and-quit.
- Open on a 1920 by 1080 screen but window is smaller than ???.
- Open on a 1920 by 1440 screen and window is exactly ???.
So, what is ??? in this scenario? :-)
And what are the results of...
Display platformScaleFactor. Display uiScaleFactor.
Best, Marcel
Am 30.05.2022 19:02:24 schrieb tim Rowledge :
Sorry if I wasn't clear - it's the *host* window size that is messed up for me.
On 2022-05-30, at 2:40 AM, Marcel Taeumel wrote:
Hi Tim --
Are you referring to the host-window size or the system-window size? I think you mean the latter. Whether or not the scale factor is involved, you can check by looking at what is selected in "Extras > Scale Factor" menu.
I am not sure that I really understand what you mean. However, there are two hard-coded numbers in RealEstateAgent class >> #strictlyStaggeredInitialFrameFor:... which we did not adjust to the scale factor.
... "Number to be staggered at each corner (less on small screens)" maxLevel := allowedArea area > 300000 ifTrue: [3] ifFalse: [2]. "Amount by which to stagger (less on small screens)" grid := allowedArea area > 500000 ifTrue: [40] ifFalse: [20]. ...
Would you apply a "* self scaleFactor" to those areas and see if the problem gets fixed? :-) Maybe also the grid.
This is most likely not a VM issue but related to a feature in newer VMs. It might be that a newer VM will actually deliver that platformScaleFactor which will then set the image-side uiScaleFactor which will then modify the "RealEstateAgent scaleFactor" which will then result in bigger default-window areas and thus hit those magic boundaries. Not sure.
Best, Marcel
Am 29.05.2022 20:54:38 schrieb tim Rowledge :
I'm just trying the latest release VM (ARMv8 on a Pi in this case) and it seems to be doing Odd Things with the window size.
The same image on two different Pis opens with different window sizes. One Pi has a 1920@180 screen and the initial window is notably smaller than what it was when I saved the image, the other has a 1920@1440 screen and the initial window size is what I set. That size is not larger than the 1920@1080 screen, by the way. To the best of my recollection this is new (mis)behaviour.
We've always done some startup checks in the VM to fit the window within the available display limits but I don't remember previously over-riding the requested size this aggressively. Has anyone changed this code recently? Or is this a side effect of recent scale factor stuff? I can't spot any suspicious code in the image right now.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim A misplaced modifier walks into a bar owned a man with a glass eye named Ralph
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- Always responds to "Make Money Fast" postings on the Net.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: VMB: Verify, then Make Bad
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Fractured Idiom:- VENI, VIDI, VISA - I came, I saw, I bought
Hi tim
On 1. Jun 2022, at 21:18, tim Rowledge tim@rowledge.org wrote:
With latest armv8 vm (https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/download/latest-b...) and updating my image it's the same situation.
The only new information is that I tried making the display window *smaller* and saving, and that reopens in the smaller size; so I have to assume that nothing has broken in the setting of the magic size-value in the image header, nor in the reading of that and trying to set the window size.
Also, using an older 5.3 clean image on this latest VM shows the same issue, so it isn't purely the image code
We really need the info of Display platformScaleFactor. Display uiScaleFactor. to dig deeper here…
-t
On 2022-06-01, at 2:19 AM, Marcel Taeumel marcel.taeumel@hpi.de wrote:
Hi Tim --
Hmm... I cannot reproduce that in Ubuntu 18. What I can reproduce is a very strange behavior of primitiveHostWindowSizeSet in X11. I will look into that.
Best, Marcel
Am 31.05.2022 19:07:53 schrieb tim Rowledge tim@rowledge.org:
Pi-4-1 screen size 1600@1200 VM /home/pi/Documents/Squeak/sqcogspur64ARMv8linuxht/lib/squeak/5.0-202205110711-64bit/squeak image squeak 6 alpha 21829 opens with display extent = 1016@702 increase to 1448@986 by usual dragging
save and quit
restart display extent is 1016@702.
Copy this file to Goldskin (another Pi 4) screen size 1920@1440 VM /home/pi/Documents/Squeak/sqcogspur64ARMv8linuxht/lib/squeak/5.0-202205110711-64bit/squeak opens with display extent1448@986 drag to extent 1632@1092 save and quit reopen display extent is 1632@1092
copy *that* back to Pi-4-1 display extent ... 1016@702
On 2022-05-31, at 8:26 AM, Marcel Taeumel wrote:
Okay. Let my try to understand what is happening here.
Platform: LinuxARMv8
- Resize window to ??? then save-and-quit.
- Open on a 1920 by 1080 screen but window is smaller than ???.
- Open on a 1920 by 1440 screen and window is exactly ???.
So, what is ??? in this scenario? :-)
And what are the results of...
Display platformScaleFactor. Display uiScaleFactor.
Best, Marcel
Am 30.05.2022 19:02:24 schrieb tim Rowledge :
Sorry if I wasn't clear - it's the *host* window size that is messed up for me.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- Always responds to "Make Money Fast" postings on the Net.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: VMB: Verify, then Make Bad
tim
On 2022-06-01, at 12:27 PM, Tobias Pape Das.Linux@gmx.de wrote:
We really need the info of Display platformScaleFactor.
-> 1.0
Display uiScaleFactor.
-> 1.0 Some additional info:
using the fullscreen button in the top-right of the dock results in a display extent of 1024@768 ! The usual take-over of the entire screen by covering the host top menubar happens, it's just that the squeak window area is only part of the actual screen ;-)
Maybe sometihng is causing the X stuff to report incorrect number? DisplayScreen class>>#setNewScreenSize: appears to work correctly even with a large size. DisplayScreen class>>#actualScreenSize simply reports the same as the Display extent, though I could swear it should report the size of the actual glass being used?
All a bit odd, especially since Bruce does not see the problem on a nominally similar setup.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- His head whistles in a cross wind.
Well, this is annoying.
I inspected the Pi config.txt to compare the problematic one to the working one wrt display settings. I found differences and 'corrected' them and rebooted. No change. I removed the changes and rebooted; now it wouldn't even open a proper vnc window. Try some more; finally a vnc window again. Notice that the preferences tool for the display doesn't appear to know of any display on the problem Pi but does on the other. Try stuff. No change.
Run OS updates. Reboot. Now it behaves as we would expect.
OK, so now it works (yay!) but I don't have any idea what was wrong and whether it is important to know for future systems (boo!)
Life with computers....
On 2022-06-01, at 12:51 PM, tim Rowledge tim@rowledge.org wrote:
On 2022-06-01, at 12:27 PM, Tobias Pape Das.Linux@gmx.de wrote:
We really need the info of Display platformScaleFactor.
-> 1.0
Display uiScaleFactor.
-> 1.0 Some additional info:
using the fullscreen button in the top-right of the dock results in a display extent of 1024@768 ! The usual take-over of the entire screen by covering the host top menubar happens, it's just that the squeak window area is only part of the actual screen ;-)
Maybe sometihng is causing the X stuff to report incorrect number? DisplayScreen class>>#setNewScreenSize: appears to work correctly even with a large size. DisplayScreen class>>#actualScreenSize simply reports the same as the Display extent, though I could swear it should report the size of the actual glass being used?
All a bit odd, especially since Bruce does not see the problem on a nominally similar setup.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- His head whistles in a cross wind.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Computer and car salesmen differ in that the latter know when they are lying.
Anyway! Your concern helped raise that issue about X11 and host-window resizing. Thanks for that! :-)
Best, Marcel Am 01.06.2022 23:19:04 schrieb tim Rowledge tim@rowledge.org: Well, this is annoying.
I inspected the Pi config.txt to compare the problematic one to the working one wrt display settings. I found differences and 'corrected' them and rebooted. No change. I removed the changes and rebooted; now it wouldn't even open a proper vnc window. Try some more; finally a vnc window again. Notice that the preferences tool for the display doesn't appear to know of any display on the problem Pi but does on the other. Try stuff. No change.
Run OS updates. Reboot. Now it behaves as we would expect.
OK, so now it works (yay!) but I don't have any idea what was wrong and whether it is important to know for future systems (boo!)
Life with computers....
On 2022-06-01, at 12:51 PM, tim Rowledge wrote:
On 2022-06-01, at 12:27 PM, Tobias Pape wrote:
We really need the info of Display platformScaleFactor.
-> 1.0
Display uiScaleFactor.
-> 1.0 Some additional info:
using the fullscreen button in the top-right of the dock results in a display extent of 1024@768 ! The usual take-over of the entire screen by covering the host top menubar happens, it's just that the squeak window area is only part of the actual screen ;-)
Maybe sometihng is causing the X stuff to report incorrect number? DisplayScreen class>>#setNewScreenSize: appears to work correctly even with a large size. DisplayScreen class>>#actualScreenSize simply reports the same as the Display extent, though I could swear it should report the size of the actual glass being used?
All a bit odd, especially since Bruce does not see the problem on a nominally similar setup.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- His head whistles in a cross wind.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Computer and car salesmen differ in that the latter know when they are lying.
squeak-dev@lists.squeakfoundation.org