xpra icon
Bug tracker and wiki

Opened 4 years ago

Closed 3 years ago

#1354 closed defect (fixed)

maximizing browsers on multi-display setup is sizing wrongly

Reported by: alas Owned by: J. Max Mena
Priority: minor Milestone: 1.0
Component: client Version: trunk
Keywords: Cc:

Description

Testing with both 1.0 r14402 fedora 23 server against a 1.0 r14397 windows client and 0.17.1 r 12453 fedora 23 server against a 0.17.5 r13487 windows client... with two displays, I'm finding that maximizing a browser window (chrome, firefox) causes it to size across both displays... but only if I maximize from the left-most display.

Fullscreen with videos behaves as expected.

I'll attach client-side logs for both combinations with -d window... looks like there's a init_max_window_size(..) max-window-size changed from (0, 0) to (4096, 4096), because of max viewport dims (8192, 8192) and max backing dims (4096, 4096) call being made in each case, with a desktop/display set up of:

 desktop size is 3840x1080 with 1 screen:
  Default (1016x285 mm - DPI: 96x96) workarea: 3840x1040
    DISPLAY1 1920x1080 at 1920x0 (621x341 mm - DPI: 78x80) workarea: 1920x1040
    DISPLAY2 1920x1080 (621x341 mm - DPI: 78x80) workarea: 1920x1040
  • Another extremely interesting note... this only happens when both displays are very close to the same size (both 1920 x 1080; one 1920 x 1080 and the other 1920 x 1200; one 1920x1080 the other 1920x1440; 1920x1080 & 2048x1536... but as soon as I reach 1920x1080 & 2560x1440 the maximize begins to behave as expected.

Attachments (10)

ticket1354_1-0-maximize-on-left-display-sprawls-across-both-displays.txt (10.0 KB) - added by alas 4 years ago.
1.0 client logs with -d window
ticket1354_0-17_maximize-on-left-display-stretches-across-both-displays.txt (15.7 KB) - added by alas 4 years ago.
0.17.x client logs with -d window
1354undecorated.txt (18.2 KB) - added by J. Max Mena 4 years ago.
Connected, maximized, unmaximized, disconnected
1354maxsizehint.txt (22.8 KB) - added by J. Max Mena 4 years ago.
Connected, maximized, unmaximized, disconnected
1354geometry.txt (23.9 KB) - added by J. Max Mena 4 years ago.
Connected, maximized, unmaximized, disconnected - this one worked as expected
1354working.txt (95.8 KB) - added by J. Max Mena 4 years ago.
Requested log - connected, moved Firefox to the right monitor, maximized and unmaximized twice, moved it to the left monitor, then maximized and unmaximized twice
window_hooks.py (6.1 KB) - added by Antoine Martin 4 years ago.
try to always clamp to the monitor size when maximized
window_hooks.2.py (5.0 KB) - added by Antoine Martin 4 years ago.
just continue to run the other minmax hooks after our one
window_hooks.3.py (5.0 KB) - added by Antoine Martin 4 years ago.
continue - but via return value
window_hooks.4.py (5.2 KB) - added by Antoine Martin 4 years ago.
preserve existing size restrictions if any

Download all attachments as: .zip

Change History (24)

Changed 4 years ago by alas

1.0 client logs with -d window

Changed 4 years ago by alas

0.17.x client logs with -d window

comment:1 Changed 4 years ago by Antoine Martin

Owner: changed from Antoine Martin to alas

Are there any differences between the 1.0 branch and 0.17? Is this a regression?
The log sample for 1.0 does have a maxmimize event:

configure event: current size=(930, 517), new size=(4096, 4096), backing=gtk2.GLWindowBacking(2, (930, 517), None), iconified=False

But the 0.17.x does not.
It would be good to have working case vs non-working case, using the same xpra version - to make it easier to compare.

It could also be opengl related: have you tried turning it off? (or on?)

Can you try to run the client with XPRA_WIN32_WINDOW_HOOKS=0 to see if that makes any difference?
If it does, then it's going to be one of those flags (unset XPRA_WIN32_WINDOW_HOOKS first): XPRA_WIN32_UNDECORATED_STYLE=0, or XPRA_WIN32_MAX_SIZE_HINT=0 or XPRA_WIN32_GEOMETRY=0.

Please include the debug output with these extra debug flags: "geometry", "screen" and "win32".

comment:2 Changed 4 years ago by J. Max Mena

Owner: changed from alas to Antoine Martin

It could also be opengl related: have you tried turning it off? (or on?)


Turning OpenGL off causes the misbehavior to stop.


Can you try to run the client with XPRA_WIN32_WINDOW_HOOKS=0 to see if that makes any difference?


Yes, it makes a difference. I uhh can't maximize anymore - the option is greyed out. So, technically that fixes it. However, I have a feeling that's not an elegant solution.


Option Effect?
XPRA_WIN32_UNDECORATED_STYLE=0 no
XPRA_WIN32_MAX_SIZE_HINT=0 no
XPRA_WIN32_GEOMETRY=0 fixed it!

Looks like the XPRA_WIN32_GEOMETRY=0 option fixed it. Will attach requested logs in a sec (on other machine)

Changed 4 years ago by J. Max Mena

Attachment: 1354undecorated.txt added

Connected, maximized, unmaximized, disconnected

Changed 4 years ago by J. Max Mena

Attachment: 1354maxsizehint.txt added

Connected, maximized, unmaximized, disconnected

Changed 4 years ago by J. Max Mena

Attachment: 1354geometry.txt added

Connected, maximized, unmaximized, disconnected - this one worked as expected

comment:3 Changed 4 years ago by J. Max Mena

Note: I was testing this with a Win8.1 machine with two 1080p monitors attached (one is a 1440p monitor, the other is 4K, but I lowered the resolutions to match), with a r14469 trunk client against a trunk r14470 Fedora 24 server.

My steps were very straight forward:

  • Connect
  • Maximize Firefox
  • Unmaximize Firefox

comment:4 Changed 4 years ago by Antoine Martin

Owner: changed from Antoine Martin to J. Max Mena

The XPRA_WIN32_GEOMETRY controls whether we hook apply_maxsize_hints or not.
When we hook it, we will ensure windows don't grow bigger than a certain size. This is needed if the application makes that request, or if we do. ie: to ensure we don't overflow the opengl texture / viewport limits, or to keep it within the "workspace" area.
We use our own hook because if we leave to GTK, it hides the maximize button, as you found out.

From your log sample, I see:

apply_maxsize_hints(GLClientWindow(2 : gtk2.GLWindowBacking(2, (1248, 848), None)), \
    {'max_width': 4096, 'min_height': 118, 'base_width': 300, 'max_height': 4096, 'min_width': 300, 'base_height': 118}) found max: 4096x4096

Then later on the system uses our hook to constrain the window geometry:

on_getminmaxinfo window=0x140822 max_size=(4096, 4096), frame=8x8, minmaxinfo size=4112x4135

And also:

OpenGL enabled with Intel(R) Iris(TM) Graphics 5100

It's very likely that this chipset is limited to 4kx4k textures (you can verify with the opengl_check.exe tool)

causes it to size across both displays... but only if I maximize from the left-most display


You're not stating what happens if you're on the right-most display.
Does it maximize only on that monitor?
What is the difference between "undecorated" and "maxsizehint" logs?
Do you have logs of "working" (left) and not-working (right) doing the same steps to compare?

I can't reproduce at the moment since virtualbox doesn't do enough opengl to test.

Changed 4 years ago by J. Max Mena

Attachment: 1354working.txt added

Requested log - connected, moved Firefox to the right monitor, maximized and unmaximized twice, moved it to the left monitor, then maximized and unmaximized twice

comment:5 Changed 4 years ago by J. Max Mena

Owner: changed from J. Max Mena to Antoine Martin

If I move Firefox to the right monitor, it'll maximize and unmaximize fine (as in on the correct monitor). Maximizing and unmaximizing on the left monitor causes the browser to maximize across both monitors.


What is the difference between "undecorated" and "maxsizehint" logs?


I used the XPRA_WIN32_UNDECORATED_STYLE=0 flag in the "undecorated" log, and the XPRA_WIN32_MAX_SIZE_HINT=0 flag in the "maxsizehint" log. Same steps for all of them.


Do you have logs of "working" (left) and not-working (right) doing the same steps to compare?


Just attached another log sample. This time, I connected, then moved firefox to the rightmost monitor and maximized and unmaximized a couple times. After a second, I moved it to the left monitor and did the same. On the right monitor it maximized fine, and on the left it maximized across both displays.


Passing back to you.

Changed 4 years ago by Antoine Martin

Attachment: window_hooks.py added

try to always clamp to the monitor size when maximized

Changed 4 years ago by Antoine Martin

Attachment: window_hooks.2.py added

just continue to run the other minmax hooks after our one

Changed 4 years ago by Antoine Martin

Attachment: window_hooks.3.py added

continue - but via return value

comment:6 Changed 4 years ago by Antoine Martin

Owner: changed from Antoine Martin to J. Max Mena

I thought I could still test a fix for this with virtualbox by artificially constraining the window size using the --max-size switch, but this is behaving as it should on my XP test vm.

I have attached 4 possible fixes which you can try ("window_hooks.*py")
To try them, either make a new win32 build from source after replacing the trunk version of the file with one of the files attached, or:

  • install the latest trunk
  • open xpra's library.zip archive in the file explorer (7-zip does it)
  • delete xpra/platform/win32/window_hooks.pyc
  • drop the replacement file in that same folder, renaming it to "window_hooks.py"
  • make sure the updated library.zip file is saved (ie: closing the file explorer window should be enough)
  • run the client and test it (the log output with "-d win32" should show some new "is-maximized" debug output with the first patch)

Rinse and repeat for each potential fix.

If that does not help, please include the "-d all" of just the maximize event for both successful and unsuccessful cases.

Last edited 4 years ago by Antoine Martin (previous) (diff)

Changed 4 years ago by Antoine Martin

Attachment: window_hooks.4.py added

preserve existing size restrictions if any

comment:7 Changed 3 years ago by J. Max Mena

This one will have to wait a bit as Smo can't get me builds at the moment, and 7Zip isn't playing nicely and won't let me add files to the archive. (lets me delete no problem)

Last edited 3 years ago by J. Max Mena (previous) (diff)

comment:8 Changed 3 years ago by Antoine Martin

FYI: on my systems I can just double-click on the library.zip to open it up in windows explorer, then I can just drag and drop files inside the archive.
Alternatively, you could use the command line: unzip, modify, zip it again.

comment:9 Changed 3 years ago by J. Max Mena

Found a workaround - copying the file to another folder under my User directory, I can edit it no problems. (ugh Windows and permissions, blegh)

Dropping in the replacement .py file causes the client to no longer connect. I think it doesn't like that I'm replacing a .pyc with a .py file.

Not sure what to do here. Either way, still no builds from Smo - will ping him.

comment:10 Changed 3 years ago by Antoine Martin

I think it doesn't like that I'm replacing a .pyc with a .py file.


Do not rename the file. Just copy it as ".py" to the target directory after removing the corresponding ".pyc". Without editing or renaming.

comment:11 Changed 3 years ago by J. Max Mena

That's what I did and it still complains about not being able to import the library.

comment:12 Changed 3 years ago by J. Max Mena

Owner: changed from J. Max Mena to Antoine Martin

Okay, thanks to Smo's hard work, I managed to get 4 different libraries to test. The client is a 1.0 r14492 Win8.1 and the server is at Fedora 24 1.0 r14576.

Here, I'll make a handy table. On the left, I'll note which library file I'm using (each corresponds to the window_hooks) attached to this ticket, and on the right I'll mark if it works and fixes the issue or not.

Which library? Works?
1 works
2 doesn't work
3 doesn't work
4 works

Looks like the first and fourth window_hoooks.py are the ones that fix it. Passing back to you. Let me know if you want any more logs.

comment:13 Changed 3 years ago by Antoine Martin

Owner: changed from Antoine Martin to J. Max Mena

@maxmylyn: thanks!

Applied version 4 of the patch to trunk in r14581, r14582 for v1.0.x

comment:14 Changed 3 years ago by J. Max Mena

Resolution: fixed
Status: newclosed

That did it! Closing.

(tested with the r14619 Win client)

Note: See TracTickets for help on using tickets.