The Trunk: Graphics-mt.332.mcz

Marcel Taeumel uploaded a new version of Graphics to project The Trunk:
http://source.squeak.org/trunk/Graphics-mt.332.mcz

==================== Summary ====================

Name: Graphics-mt.332
Author: mt
Time: 7 May 2016, 9:48:30.374081 am
UUID: 7fc10c6a-d146-584d-8e94-7153042d37d9
Ancestors: Graphics-nice.331

Cherry-pick and adapt eToys' way to set the screen size programmatically via HostWindowPlugin.

=============== Diff against Graphics-nice.331 ===============

Item was changed:
  Form subclass: #DisplayScreen
  instanceVariableNames: 'clippingBox extraRegions'
+ classVariableNames: 'DeferringUpdates DisplayChangeSignature DisplayIsFullScreen ScreenSave'
- classVariableNames: 'DeferringUpdates DisplayChangeSignature ScreenSave'
  poolDictionaries: ''
  category: 'Graphics-Display Objects'!
 
  !DisplayScreen commentStamp: '<historical>' prior: 0!
  There is only one instance of me, Display. It is a global and is used to handle general user requests to deal with the whole display screen.
  Although I offer no protocol, my name provides a way to distinguish this special instance from all other Forms. This is useful, for example, in dealing with saving and restoring the system.
  To change the depth of your Display...
  Display newDepth: 16.
  Display newDepth: 8.
  Display newDepth: 1.
  Valid display depths are 1, 2, 4, 8, 16 and 32.  It is suggested that you run with your monitors setting the same, for better speed and color fidelity.  Note that this can add up to 4Mb for the Display form.  Finally, note that newDepth: ends by executing a 'ControlManager restore' which currently terminates the active process, so nothing that follows in the doit will get executed.
 
  Depths 1, 2, 4 and 8 bits go through a color map to put color on the screen, but 16 and 32-bit color use the pixel values directly for RGB color (5 and 8 bits per, respectivlely).  The color choice an be observed by executing Color fromUser in whatever depth you are using.
  !

Item was removed:
- ----- Method: DisplayScreen class>>depth:width:height:fullscreen: (in category 'display box access') -----
- depth: depthInteger width: widthInteger height: heightInteger fullscreen: aBoolean
- "Force Squeak's window (if there's one) into a new size and depth."
- "DisplayScreen depth: 8 width: 1024 height: 768 fullscreen: false"
-
- <primitive: 92>
- self primitiveFailed!

Item was added:
+ ----- Method: DisplayScreen class>>displayIsFullScreen (in category 'screen modes') -----
+ displayIsFullScreen
+
+ ^ DisplayIsFullScreen ifNil: [DisplayIsFullScreen := false]!

Item was added:
+ ----- Method: DisplayScreen class>>fullScreenOff (in category 'screen modes') -----
+ fullScreenOff
+
+ Display fullScreenMode: (DisplayIsFullScreen := false).
+ self checkForNewScreenSize.
+ !

Item was added:
+ ----- Method: DisplayScreen class>>fullScreenOn (in category 'screen modes') -----
+ fullScreenOn
+
+ Display fullScreenMode: (DisplayIsFullScreen := true).
+ self checkForNewScreenSize.!

Item was added:
+ ----- Method: DisplayScreen class>>hostWindowExtent: (in category 'host window access') -----
+ hostWindowExtent: aPoint
+
+ ^ self
+ primitiveWindow: self hostWindowIndex
+ width: aPoint x
+ height: aPoint y!

Item was added:
+ ----- Method: DisplayScreen class>>hostWindowIndex (in category 'host window access') -----
+ hostWindowIndex
+
+ ^ 1!

Item was added:
+ ----- Method: DisplayScreen class>>hostWindowTitle: (in category 'host window access') -----
+ hostWindowTitle: aString
+
+ ^ self
+ primitiveWindow: self hostWindowIndex
+ title: aString squeakToUtf8!

Item was added:
+ ----- Method: DisplayScreen class>>primitiveWindow:title: (in category 'host window access') -----
+ primitiveWindow: id title: titleString
+
+ <primitive: 'primitiveHostWindowTitle' module: 'HostWindowPlugin'>
+ ^self primitiveFailed!

Item was added:
+ ----- Method: DisplayScreen class>>primitiveWindow:width:height: (in category 'host window access') -----
+ primitiveWindow: id width: width height: height
+
+ <primitive: 'primitiveHostWindowSizeSet' module: 'HostWindowPlugin'>
+ ^self primitiveFailed!

Item was added:
+ ----- Method: DisplayScreen class>>setNewScreenSize: (in category 'display box access') -----
+ setNewScreenSize: aPoint
+ "Ensure that the Display is set to the given extent. Due to the behavior of host-window plugin, this may need two attempts because the plugin tends to account for host window shadows and title bars."
+
+ self hostWindowExtent: aPoint.
+ self checkForNewScreenSize.
+
+ Display extent < aPoint ifTrue: [
+ self hostWindowExtent: 2*aPoint - Display extent.
+ self checkForNewScreenSize].!

Item was added:
+ ----- Method: DisplayScreen class>>toggleFullScreen (in category 'screen modes') -----
+ toggleFullScreen
+ "Toggle between full screen and windowed mode."
+
+ self displayIsFullScreen
+ ifTrue: [self fullScreenOff]
+ ifFalse: [self fullScreenOn].!

On Sat, 7 May 2016, [hidden email] wrote:

As I mentioned in an earlier discussion, HostWindowProxy doesn't work on
Linux. At least not with Cog VMs.

Levente

It does on my linux vms, with Cog, for Pi. Which ought to mean for any *nix. It’s how I set the window size for a Scratch release.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Disclaimer:  Any errors in spelling, tact, or fact are transmission errors.

On Sun, May 08, 2016 at 08:45:59AM -0700, tim Rowledge wrote:
I think this is Mantis 7833: You can not switch back from fullscreen on a linux 64-bit system

  http://bugs.squeak.org/view.php?id=7833

The fix was applied last November (SVN trunk and oscog) and is present in
current interpreter and Cog/Spur VMs.

Older VMs, possibly including the All-in-one, would have the bug.

Dave

Hi, there.

Is it expected behavior that the HostWindowPlugin also considers window border, shadows, title bar etc. when being resized? From the Squeak perspective, the "Display extent" is expected to be exactly x@y. That's why I added #setNewScreenSize:.

Best,
Marcel

On Sun, 8 May 2016, tim Rowledge wrote:
[ DisplayScreen hostWindowExtent: 800 @ 600 ]
  on: Error
  do: [ :error | error messageText ]
==> "primitiveWindow:width:height: failed"

((1001 to: 1009) collect: [ :each | Smalltalk getSystemAttribute: each ])
joinSeparatedBy: String cr "==>

"unix
linux-gnu
x86_64
Croquet Closure Cog[Spur] VM [CoInterpreterPrimitives VMMaker.oscog-eem.1834]
X11
Unix built on Apr 22 2016 22:27:34 Compiler: 4.4.7 20120313 (Red Hat 4.4.7-4)
CoInterpreter VMMaker.oscog-eem.1834 uuid: 858a9c54-959b-4d7e-b9b3-5f083d37f488 Apr 22 2016
StackToRegisterMappingCogit VMMaker.oscog-eem.1832 uuid: 3e4d6e88-f60d-4a01-930d-7c5895b8a86a Apr 22 2016
VM: r3684 http://www.squeakvm.org/svn/squeak/branches/Cog Date: 2016-04-22 21:32:43 -0700 Plugins: r3639
http://squeakvm.org/svn/squeak/trunk/platforms/Cross/plugins"

Levente

>
> tim
> --
> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
> Disclaimer:  Any errors in spelling, tact, or fact are transmission errors.
>
>
>
>

Hi Levente,

there are no-display checks for the calls:

#define noDisplay ( (!dpy && !(dpy= ioGetDisplayModule())) || (dpy->version < 0x10002) )

in platforms/unix/plugins/HostWindowPlugin/sqUnixHostWindowPLugin.c

Maybe the OpenGL version in your system is an issue?

Best,
Marcel

The thing is that there's no HostWindowPlugin at all in http://www.mirandabanda.org/files/Cog/VM/latest/cogspur64linuxht-16.18.3692.tgz .
And no, OpenGL works just fine from the same image/vm.

Levente

On Mon, 9 May 2016, marcel.taeumel wrote:

> On 09-05-2016, at 3:16 AM, Levente Uzonyi <[hidden email]> wrote:
>
> The thing is that there's no HostWindowPlugin at all in http://www.mirandabanda.org/files/Cog/VM/latest/cogspur64linuxht-16.18.3692.tgz .

Dang, he’s right. There is no building of HostWindowPlugin in the linux build trees I’ve checked. Which must mean I’ve only ever set the size of the Scratch window on my iMac, which is seriously weirding me. I would *swear* (loudly) that we’ve been building with it included. Oh well, let’s try it out and see.

{later} damnitstupidmake
{later} damnintstupidirritatingmake
{time passes…}at last it’s in the buildlist
{late}ooh it appears to build…
{later} it produces the blank white screen Yoshiki mentioned. Bugger.


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
"Bother!" said Pooh, as Piglet pressed <START> on the Microwave...

> On 09-05-2016, at 10:44 AM, tim Rowledge <[hidden email]> wrote:
>
> {later} it produces the blank white screen Yoshiki mentioned. Bugger.

Rebuild to leave out hostwindowplugin just in case…

Nope; no difference. So, somewhere between 3633 & 3692 we’ve borked the unix related display stuff. Happy Happy!

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Oxymorons: Clearly misunderstood

Tim,

I was looking at this last night (trying to see how much difference we
have in sqUnixX11.c in the branches, yikes), and I noticed that
platforms/unix/sqHostWindowPlugin.c in oscog is missing the type
declaration fixes for things declared int that should be sqInt. Copy the
one from SVN trunk for a quick fix, sorry I can't look at it myself right
now.

This would affect 64 bit only, so probably not part of the problem, but
just so you know.

Dave

On Mon, May 09, 2016 at 10:44:22AM -0700, tim Rowledge wrote:
Background: Marcel updated DisplayScreen methods to use HostWindowPlugin
to set the Squeak window size and window title. Meanwhile, Tim is trying
to get the plugin to compile for a Unix VM for Raspberry Pi.

But this cannot possibly work. The window index used by HostWindowPlugin
is supposed to be opaque value, known to the plugin but not to the image.
On a Windows platform, the window index might be 1. This is the value
that we currently have hard-coded in DisplayScreen class>>hostWindowIndex.
On a platform with X11 display, the host window index is an integer value
of type Window, which might be a value such as 16rA00001 (as tested on
my PC a few minutes ago:

     xwininfo: Window id: 0x3a00001 "squeak.image"

For a Unix VM, the HostWindowPlugin delegates to methods in
platforms/unix/vm-display-X11/sqUnixX11.c, which contains a check to make
sure that all window handles are are integer values greater than 16rFFFF
(so of course a value of 1 will fail). Presumably this is because the
designers of X11 wanted to ensure that their window handles would be values
that could not be easily confused with integers such as 0, 1, 2, 3, ... and
most likely Ian Piumarta was aware of this and added the check to fail the
primitive if the window handle was a value such as 1.

Therefore if Tim gets the HostWindowPlugin to compile, it is not going
to work anyway.

I suspect that we are missing something here with respect to the earlier
Qwaq code, which presumably did work. The missing thing seems to be a
way to obtain a handle for the Squeak display window. Possibly we could
use one additional HostWindowPlugin primitive to provide this information,
such that DisplayScreen class>>hostWindowIndex could call that primitive
rather than assuming a hard-coded value of 1.

I also would guess that Qwaq actually did the Right Thing, which would
be to let the image open its main display window by requesting it from
the VM (HostWindowPlugin in this case), and letting the plugin provide
the window handle as the result of that request. IMO that would be the
right way to do it for Squeak also, but for purposes of backward compatibility
in the near term, a HostWindowPlugin>>primitiveDefaultDisplayWindow would
be sufficient. On Windows, it would probably answer 1, and on X11 it would
answer the Window handle of the Squeak application window.

Dave

On Tue, May 10, 2016 at 09:59:25PM -0400, David T. Lewis wrote:
One additional follow up: I just confirmed that if I find the Window ID
of my Squeak window (using unix utility xwininfo), and use that value
as the window handle, then the Squeak window resize does work. At least
the window gets resized and the primitive does not fail, although I am
not entirely certain if my window ID is the stWindow or the stParent
window, so the resizing behavior may be off by a few pixels.

I did this:

   hostWindowIndex := 16r3800001.
   [ DisplayScreen
    primitiveWindow: hostWindowIndex
    width: 800
    height: 600 ]
           on: Error
           do: [ :error | error messageText ]

The 16r3800001 window ID is what I got from running xwininfo, so I was
using this as the window handle in the call to the HostWindowPlugin primitive.

Disclaimer: I am testing with an interpreter VM with Qwaq enhancements
harvested from oscog added to sqUnixX11.c on my PC, not committed to SVN.
This is theoretically equivalent to the latest Cog/Spur but YMMV.

Dave

>
> But this cannot possibly work. The window index used by HostWindowPlugin
> is supposed to be opaque value, known to the plugin but not to the image.
> On a Windows platform, the window index might be 1.

IIRC (after all, I wrote this 12 years ago) we defined that the ‘root’ window had to have a 1 index just so we could rely upon something.


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
You never finish a program, you just stop working on it.

On 11.05.2016, at 07:32, tim Rowledge <[hidden email]> wrote:

>>
>> But this cannot possibly work. The window index used by HostWindowPlugin
>> is supposed to be opaque value, known to the plugin but not to the image.
>> On a Windows platform, the window index might be 1.
>
> IIRC (after all, I wrote this 12 years ago) we defined that the ‘root’ window had to have a 1 index just so we could rely upon something.

Yep. That's why it's hard-coded in DisplayScreen but a variable in HostWindowProxy.

- Bert -

On Wed, May 11, 2016 at 10:47:11AM +0200, Bert Freudenberg wrote:
Hmmm... it looks to me like it may take some work to make the unix
plugin work that way. But maybe I was just overlooking something.

Dave

On 11.05.2016, at 15:02, David T. Lewis <[hidden email]> wrote: The version I see here actually works *only* for the main Squeak window:

static int display_hostWindowSetTitle(int windowIndex, char *newTitle, int sizeOfTitle)
{
  if (windowIndex != 1)
    return -1;

  XChangeProperty(stDisplay, stParent,
                  XInternAtom(stDisplay, "_NET_WM_NAME", False),
                  XInternAtom(stDisplay, "UTF8_STRING",  False),
                  8, PropModeReplace, newTitle, sizeOfTitle);

  return 0;
}

(and setting the size is not implemented)

static int display_hostWindowSetSize(int windowIndex, int w, int h)
{ return -1; }

- Bert -

On Wed, May 11, 2016 at 03:35:49PM +0200, Bert Freudenberg wrote:
Aha, that gives me an idea. If the established convention is that window
handle 1 refers to the Squeak display window, then maybe we can maintain
the convention by having sqUnixX11.c check for this and convert it to the
actual X11 Window of the display window.

The code that you quote above is the current SVN trunk. The oscog branch
has the same implementation for display_hostWindowSetTitle, and adds various
things from Qwaq including a display_hostWindowSetSize(). The Qwaq methods
all to use the X11 Window as the handle, and that is the part that does
not yet work.

So maybe there is an easy fix, convert index 1 to the window handle
of the display window, stParent. For all other cases, treat the handles
as opaque values. Yes, I think it will work :-)

Dave

On Wed, May 11, 2016 at 10:45:49PM -0400, David T. Lewis wrote:
Sorry for replying to my own post, but I found one more "aha".

I now know that the original intent of the window handles for the host
window plugin included an assumption that handle 1 should always refer
to the main Squeak display. But I also know from Andreas' previous work
that any time the VM (a plugin) provides a "handle" reference to something
internal to that plugin, that it was very important that the handle be
treated as an opaque reference. In other words, the image should not be
able to decode that handle to figure out what was going on internally
within the plugin (as I routinely did with e.g. UnixOSProcessPlugin, to
Andreas' great dismay).

So, based on that background, I was expecting that the host window
handles in HostWindowPlugin would be treated in the same manner, and
that is why I was surprised to find that DisplayScreen class>>hostWindowIndex
was hard coded to answer 1, when I might have expected that it should
instead ask the VM for an opaque handle to the Squeak display window.

<OT>I came up with a workaround for the X11 display module that simply
maps host window handle 1 to the actual display window. That works
very well, and I can now resize the display window on a unix VM.
Based on that, I put an update in the inbox, which should be good
independent of this discussion. </OT>

I then took a look at some of the other Qwaq updates to sqUnixX11.c,
and I see that there are more recent updates that (AFIK) are not yet
in use in the Squeak VMs. These are identified by a version level
in vm/SqDisplay.h (SqDisplayVersionMinor >= 3). One of the newer
methods is:

  void *display_ioGetWindowHandle() { return (void *)stParent; }

This is exactly what I would have expected. stParent is the address of
a Window struct for the X11 window that contains the Squeak display.
The handle in this case would be a 32-bit or 64-bit C pointer, and the
expectation would be that the image should treat this as an opaque handle,
meaningful to the VM but serving only as a handle reference within the
image.

My opinion:

For our immediate purposes, we should respect the convention of treating
host window handle 1 as a reference to the display window. Hack the plugin
and X11 loadable VM module as needed make it work. It does work, and I'll
post some VM patches as soon as I can (maybe a couple of days, I'm done
looking at it for now).

But what we really should do: Implement it as I believe that it was probably
done at Qwaq. The handles should be opaque, and the host window plugin
should have an addition primitive to answer the window handle for the
main host window. That primitive would, in the case of the X11 VM module,
call this to get the handle:

  void *display_ioGetWindowHandle() { return (void *)stParent; }

This can be done in a backward compatible manner, because the image
can call the primitive to obtain the main window handle, and fall back
to a default value of 1 if the primitive fails.

Dave

On 12.05.2016, at 07:42, David T. Lewis <[hidden email]> wrote: +1

This is a sensible and pragmatic approach.

The other option would be to actually have a registry in the plugin and only hand indices to the image instead of leaking raw window handles. That way the handles would be completely opaque, and couldn’t be forged by the image. Index 1 would be pre-allocated to the main window. But I agree that the added complexity in the plugin is not worth that effort.

- Bert -