#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)
Change History (25)
Changed 6 years ago by
Changed 6 years ago by
0.17.x client logs with -d window
comment:1 Changed 6 years ago by
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 6 years ago by
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 6 years ago by
Attachment: | 1354undecorated.txt added |
---|
Connected, maximized, unmaximized, disconnected
Changed 6 years ago by
Attachment: | 1354maxsizehint.txt added |
---|
Connected, maximized, unmaximized, disconnected
Changed 6 years ago by
Attachment: | 1354geometry.txt added |
---|
Connected, maximized, unmaximized, disconnected - this one worked as expected
comment:3 Changed 6 years ago by
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 6 years ago by
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 6 years ago by
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 6 years ago by
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 5 years ago by
Attachment: | window_hooks.py added |
---|
try to always clamp to the monitor size when maximized
Changed 5 years ago by
Attachment: | window_hooks.2.py added |
---|
just continue to run the other minmax hooks after our one
comment:6 Changed 5 years ago by
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.
Changed 5 years ago by
Attachment: | window_hooks.4.py added |
---|
preserve existing size restrictions if any
comment:7 Changed 5 years ago by
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)
comment:8 Changed 5 years ago by
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 5 years ago by
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 5 years ago by
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 5 years ago by
That's what I did and it still complains about not being able to import the library.
comment:12 Changed 5 years ago by
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 5 years ago by
Owner: | changed from Antoine Martin to J. Max Mena |
---|
comment:14 Changed 5 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
That did it! Closing.
(tested with the r14619 Win client)
comment:15 Changed 16 months ago by
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1354
1.0 client logs with -d window