xpra icon
Bug tracker and wiki

Opened 8 years ago

Closed 8 years ago

Last modified 6 years ago

#107 closed defect (fixed)

resizing a maximized window yield strange results

Reported by: ahuillet Owned by: Antoine Martin
Priority: major Milestone: 0.3
Component: platforms Version: 0.1.0
Keywords: Cc:

Description

Hello,

when trying to resize a maximized window, the actual window on win32 doesn't change, but it seems that the application window is resized.

See attached screenshot.

Attachments (2)

Image1.jpg (350.3 KB) - added by ahuillet 8 years ago.
xpra-windowresize.patch (20.3 KB) - added by Antoine Martin 8 years ago.
work in progress patch, definitely not ready for merging, but should work

Download all attachments as: .zip

Change History (19)

Changed 8 years ago by ahuillet

Attachment: Image1.jpg added

comment:1 Changed 8 years ago by ahuillet

Component: androidplatforms

comment:2 Changed 8 years ago by Antoine Martin

Owner: changed from Antoine Martin to ahuillet
Status: newassigned

Looks like gtk thinks that we are resizing the window, but win32 does not allow it?
Do you have any debug log from the client and server doing this? Does this happen with any app or just this one?

comment:3 Changed 8 years ago by ahuillet

Debug log? What do you need exactly?

comment:4 Changed 8 years ago by Antoine Martin

Anything related to window dimensions? Any clue in there? (and is it specific to one app, or many, etc..)

comment:5 Changed 8 years ago by ahuillet

You can reproduce the issue easily.

Start a Xpra server and start Paraview (it needs OpenGL to run, so "vglrun paraview" is usually needed).
Connect to the server with the windows client.

Maximize the window. Try to resize it. See what happens.

comment:6 Changed 8 years ago by Antoine Martin

Owner: changed from ahuillet to Antoine Martin
Status: assignedaccepted

100% reproducible, no need for vglrun or win32, works with xdummy.

Looks like the client and server disagree on whether the window is resizable, so we end up resizing the server window but not the client window... which leaves junk pixels in between.

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

comment:7 Changed 8 years ago by Antoine Martin

Summary: win32: Resizing a maximized window yield strange resultsresizing a maximized window yield strange results

comment:8 Changed 8 years ago by ahuillet

I assume you mean the opposite: we're resizing the client window but not the server's?

comment:9 Changed 8 years ago by Antoine Martin

No, just like I said above. More details below.

(this with lxde/openbox - maybe other window managers do things differently)
I can resize the window horizontally OR vertically, and everything resizes correctly (on the fly too). It only goes wrong when I resize both dimensions in one go.

I believe that's because the resizing is done by the application itself and not the window manager: there are no "do_configure_event"s firing. The widget in the window's bottom-right corner does not belong to the client's window manager.
Whatever the application is doing, it should be telling us (the server) that it is resizing itself, why are we not seeing that?

comment:10 Changed 8 years ago by Antoine Martin

In fact, everything works fine if you manage to use your client's window manager to do the resizing and not the application's widget. For openbox, that means grabbing the thin outer edge of the window. You can see the change to the window's widget because the cursor also changes (the app uses a "double arrow", my local window manager uses a "corner with arrow pointing to it").

comment:11 Changed 8 years ago by Antoine Martin

I can see the resize events in x_event_filter:

ConfigureNotify 22 event received: (0, 0, 1769, 1004)
ConfigureNotify 22 event received: (0, 0, 1699, 925)
ConfigureNotify 22 event received: (0, 0, 1683, 910)
ConfigureNotify 22 event received: (0, 0, 1679, 907)
ConfigureNotify 22 event received: (0, 0, 1674, 903)
ConfigureNotify 22 event received: (0, 0, 1626, 861)

But this never reaches anywhere in xpra's window event handlers!?

On the subject of move/resize, I found this in the ewmh spec:

	Window Managers should treat a _NET_MOVERESIZE_WINDOW message exactly 
	like a ConfigureRequest (in particular, adhering to the ICCCM rules
	about synthetic ConfigureNotify events), except that they should use
	the gravity specified in the message. 

	Rationale: Using a _NET_MOVERESIZE_WINDOW message with StaticGravity
	allows Pagers to exactly position and resize a window including its 
	decorations without knowing the size of the decorations.

Which we do not handle at present... needs adding.

comment:12 Changed 8 years ago by Antoine Martin

Looks like the app is sending the resize (ConfigureNotify event) to the wrong window.

So the "right" fix is to fix the app, I am now looking at finding a workaround by catching resize events sent to the "composite helper" and forwarding those to the correct window. That's a bit of a hack though, and might cause further problems with apps that do *not* misbehave... And so far, all I've managed to do is to prevent the client window from resizing the composite window it does not own (which is probably better behaviour than what we have now)

comment:13 Changed 8 years ago by Antoine Martin

# The purpose of the 'corral' is to keep the client window managed -- we
# select for SubstructureRedirect on it, so that the client cannot resize
# etc. without going through the WM.

Well..

composite_configure_event(..) event.geometry: (0, 0, 1473, 687)
composite_configure_event(..) corral_window: (2, 23, 2039, 1164, 24)
composite_configure_event(..) client_window: (0, 0, 1473, 687, 24)

Maybe we need ResizeRedirect too?

Anyway, I was completely wrong about the size handling: we just don't handle client (as in X11 client) side window resizing at all, which is the problem.
See r912 for a simple test app which shows the problem much more simply than paraview.

The solution is not simple: if we pass the new window dimensions (and position whilst we are at it) to the client, we risk creating loops.

Changed 8 years ago by Antoine Martin

Attachment: xpra-windowresize.patch added

work in progress patch, definitely not ready for merging, but should work

comment:14 Changed 8 years ago by Antoine Martin

The patch above fixes the issue, but may well introduce new ones... Like loops where the client and the server keep resizing the windows to match their own sizing constraints... Will need thorough testing (and test apps) on all platforms, and the wimpiggy bits are probably misnamed (need cleaning up)

comment:15 Changed 8 years ago by Antoine Martin

cleaner version of the patch merged in r1089

I haven't encountered any loops yet... but if there are some, we should be able to do something about it:

  • either ignore configure events firing from our own resize() call (assuming that they will fire straight away so we can clear the flag/embargo with a simple idle_add call - after checking that the size is not too far out, and if it is.. ??)
  • or.. accept whatever the client ends up configuring?

comment:16 Changed 8 years ago by Antoine Martin

Resolution: fixed
Status: acceptedclosed

comment:17 Changed 6 years ago by Antoine Martin

Note: see #765 for _NET_MOVERESIZE_WINDOW

Note: See TracTickets for help on using tickets.