Host window resizing (was: [Vm-dev] Re: Too many full GCs in Cog/Spur ... while just drawing GUI ...)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Host window resizing (was: [Vm-dev] Re: Too many full GCs in Cog/Spur ... while just drawing GUI ...)

Bert Freudenberg
(moving from vm-dev)

On 07.04.2016, at 13:45, marcel.taeumel <[hidden email]> wrote:
>
> DisplayScreen depth: 32 width: 1024 height: 768 fullscreen: false.

This does nothing except on Windows I believe.

I was pretty certain that at some point we added these methods from Etoys:

        DisplayScreen class>>hostWindowSize:
        DisplayScreen class>>hostWindowTitle:

(which are used to set the proper out-of-the box image size, and to display a document title)

... but I can’t find them in Trunk. Am I misremembering?

Anyway, the primitive works:

nil with: 1 with: 1024 with: 768 executeMethod: HostWindowProxy>>#primitiveWindowSize:x:y:

How about we remove DisplayScreen's depth:width:height:fullscreen: and add these instead? Alternatively, we could implement it using the hostwindow and fullscreen primitives, but since there are no senders anyway (ad it never worked on all platforms)  I’d say we can deprecate it.

- Bert -






smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Host window resizing (was: [Vm-dev] Re: Too many full GCs in Cog/Spur ... while just drawing GUI ...)

Tobias Pape

On 07.04.2016, at 15:39, Bert Freudenberg <[hidden email]> wrote:

> (moving from vm-dev)
>
> On 07.04.2016, at 13:45, marcel.taeumel <[hidden email]> wrote:
>>
>> DisplayScreen depth: 32 width: 1024 height: 768 fullscreen: false.
>
> This does nothing except on Windows I believe.
>
> I was pretty certain that at some point we added these methods from Etoys:
>
> DisplayScreen class>>hostWindowSize:
> DisplayScreen class>>hostWindowTitle:
>
> (which are used to set the proper out-of-the box image size, and to display a document title)
>
> ... but I can’t find them in Trunk. Am I misremembering?
>
> Anyway, the primitive works:
>
> nil with: 1 with: 1024 with: 768 executeMethod: HostWindowProxy>>#primitiveWindowSize:x:y:
>
Or just

HostWindowProxy new primitiveWindowSize: 1 x: 1024 y: 768.

> How about we remove DisplayScreen's depth:width:height:fullscreen: and add these instead? Alternatively, we could implement it using the hostwindow and fullscreen primitives, but since there are no senders anyway (ad it never worked on all platforms)  I’d say we can deprecate it.
>
> - Bert -





signature.asc (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Host window resizing (was: [Vm-dev] Re: Too many full GCs in Cog/Spur ... while just drawing GUI ...)

Levente Uzonyi
In reply to this post by Bert Freudenberg
On Thu, 7 Apr 2016, Bert Freudenberg wrote:

> (moving from vm-dev)
>
> On 07.04.2016, at 13:45, marcel.taeumel <[hidden email]> wrote:
>>
>> DisplayScreen depth: 32 width: 1024 height: 768 fullscreen: false.
>
> This does nothing except on Windows I believe.

It works on Unix VMs using the vm-display-null driver. We use it to resize
the window without restarting the image.

>
> I was pretty certain that at some point we added these methods from Etoys:
>
> DisplayScreen class>>hostWindowSize:
> DisplayScreen class>>hostWindowTitle:
>
> (which are used to set the proper out-of-the box image size, and to display a document title)
>
> ... but I can’t find them in Trunk. Am I misremembering?
>
> Anyway, the primitive works:
>
> nil with: 1 with: 1024 with: 768 executeMethod: HostWindowProxy>>#primitiveWindowSize:x:y:
The primitive fails on unix Spur VMs.

>
> How about we remove DisplayScreen's depth:width:height:fullscreen: and add these instead? Alternatively, we could implement it using the hostwindow and fullscreen primitives, but since there are no senders anyway (ad it never worked on all platforms)  I’d say we can deprecate it.

Sure, as soon as there's a unified way to do it on all platforms.

Levente

>
> - Bert -
>
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Host window resizing (was: [Vm-dev] Re: Too many full GCs in Cog/Spur ... while just drawing GUI ...)

timrowledge
There’s a long and complicated history to host-window sizing in Squeak. There is (or at least was, it’s been a while since I had to look) a fair bit of ugly code that tries to cope with several competing approaches.

a) initial opening of the host window on startup, where we try to open a window of the same size as the one the image was saved from. In. With? Whatever. We have to deal with possibly being on a different  size screen or on a device that limits the size somehow. I guess opening on a fixed-size framebuffer is the most restrictive.

b) after startup the user uses host UI widgets to change the window size and we have to detect that (which I think is done horribly in the image by actually polling the ‘screen’ size every now and then, rather than by having any sort of signal from the vm to the image) and rebuild the Display object

c) programmatic Display size changes; this one used to be a mess as various VMs tried to resize the host window in response to a new object being set as the vm-known display bitmap, whilst others didn’t and so on.

d) cleverer programmatic size changes driven by the ancient DisplayScreen>fullScreenMode: that expect to take over the whole device screen area whilst you remember the prior size and handle multiple (ab)uses.

e) even cleverer programmatic stuff from the Ariethfa Ffenestri project to manipulate host window sizes, positions, displaying and so on. Which was all done because people spent years claiming Squeak absolutely had to do host windows or die. Funny that nobody has done anything with it since ’04.

f) probably more that I’ve not been flayed by.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Maybe Computer Science should be in the College of Theology



Reply | Threaded
Open this post in threaded view
|

Re: Host window resizing (was: [Vm-dev] Re: Too many full GCs in Cog/Spur ... while just drawing GUI ...)

timrowledge
In reply to this post by Levente Uzonyi

> On 07-04-2016, at 8:57 AM, Levente Uzonyi <[hidden email]> wrote:
>
> On Thu, 7 Apr 2016, Bert Freudenberg wrote:
[snip]
>>
>> How about we remove DisplayScreen's depth:width:height:fullscreen: and add these instead? Alternatively, we could implement it using the hostwindow and fullscreen primitives, but since there are no senders anyway (ad it never worked on all platforms)  I’d say we can deprecate it.
>
> Sure, as soon as there's a unified way to do it on all platforms.

There is; Ffenestri. It appears that all current platforms have the HostWindowPlugin filled out, though I can’t vouch for their correctness.


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Semolina - a  system of signalling with pudding.



Reply | Threaded
Open this post in threaded view
|

Re: Host window resizing (was: [Vm-dev] Re: Too many full GCs in Cog/Spur ... while just drawing GUI ...)

Bert Freudenberg
In reply to this post by Levente Uzonyi
> On 07.04.2016, at 17:57, Levente Uzonyi <[hidden email]> wrote:
>
>> On Thu, 7 Apr 2016, Bert Freudenberg wrote:
>>
>> nil with: 1 with: 1024 with: 768 executeMethod: HostWindowProxy>>#primitiveWindowSize:x:y:
>
> The primitive fails on unix Spur VMs.

Oh. Guess that is compiled without the HostWindowPlugin? It should work in X11.

- Bert -

Reply | Threaded
Open this post in threaded view
|

Re: Host window resizing (was: [Vm-dev] Re: Too many full GCs in Cog/Spur ... while just drawing GUI ...)

marcel.taeumel
Hi, Bert.

Please add

> DisplayScreen class>>hostWindowSize:
> DisplayScreen class>>hostWindowTitle:

from eToys and deprecate the other one.

Best,
Marcel