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

tim Rowledge tim at rowledge.org
Thu Apr 7 17:26:35 UTC 2016


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; tim at rowledge.org; http://www.rowledge.org/tim
Maybe Computer Science should be in the College of Theology




More information about the Squeak-dev mailing list