Xpra: Ticket #997: restore windows which were minimized during session lock on win32

Follow up from #901:

we should keep track of the windows we minimized and restore them
we should not try to map new windows whilst the session is locked (or just minimize them immediately - and also restore those)

Fri, 13 Nov 2015 13:33:52 GMT - Antoine Martin: status, milestone changed

status changed from new to assigned
milestone changed from 1.0 to 0.17

Mon, 29 Feb 2016 05:08:58 GMT - Antoine Martin: owner, status changed

owner changed from Antoine Martin to alas
status changed from assigned to new

r12097 takes care of restoring the windows that were frozen during lock when the session is unlocked. Not mapping new windows is harder, so I am moving this one to #1138.

Ready for testing.

Thu, 03 Mar 2016 23:55:29 GMT - J. Max Mena:

Tested with the r12103 Win8.1 Client:

Windows restored properly after the lock

However, my display driver crashes every time (I saw this 3 times without any other applications open - Xpra is very much the obvious culprit) when I have OpenGL on.
- As you may have guessed, it's an Intel Iris Pro iGPU. I'm sorry.

-d win32 not showing anything interesting, at least to me. I'll attach a .txt with the logs captured from the client anyway, you may pick up on something I don't.

HOWEVER: Xpra does not crash; just the display driver.

Thu, 03 Mar 2016 23:56:03 GMT - J. Max Mena: attachment set

attachment set to xpra997win32.txt

Wed, 16 Mar 2016 06:40:46 GMT - Antoine Martin: owner changed

owner changed from alas to J. Max Mena

HOWEVER: Xpra does not crash; just the display driver.

Intel drivers...

Still, r12152 may help: we now wait before deiconifying the windows. The default delay is 1000 milliseconds, but you can change it with:

SET XPRA_DEICONIFY_DELAY=0
xpra_cmd attach ...

Let me know if any values help. I would prefer if we found an event we can wait for instead of a delay (which may not work in all cases..), there may be one following the event we already use: WM_WTSSESSION_CHANGE: SESSION_UNLOCK on session 0x1, but since you got a crash instead, maybe it never got a chance to be seen. Running again with a higher delay may show something we can use in the log output.

Thu, 17 Mar 2016 22:03:51 GMT - J. Max Mena:

@antoine: Need new Windows Beta Builds

Fri, 18 Mar 2016 11:44:27 GMT - Antoine Martin:

@maxmylyn: done!

FYI: there's another ticket for OSX which does something similar: #965.

Tue, 22 Mar 2016 20:23:13 GMT - J. Max Mena: owner changed

owner changed from J. Max Mena to Antoine Martin

Tried it a few times(half of Friday locking and unlocking, along with an hour this afternoon) with the r12161 client and it seems to be behaving for the time being. No more crashes or driver issues.

The default delay works fine. No real difference noticed when I set it to 0 or any other values (I tried 100,250,300,500).

Passing back to you.

Wed, 23 Mar 2016 13:30:54 GMT - Antoine Martin: owner changed

owner changed from Antoine Martin to J. Max Mena

@maxmylyn: thanks for testing! Since the zero-delay worked, I've changed the code in r12195 to make it better & cleaner, can you please re-test? (the XPRA_DEICONIFY_DELAY no longer exists)

Tue, 29 Mar 2016 04:42:48 GMT - Antoine Martin:

Somewhat related: ticket:540#comment:7

Tue, 12 Apr 2016 21:05:33 GMT - J. Max Mena: owner changed

owner changed from J. Max Mena to Antoine Martin

I retested this a couple weeks ago, and off and on since then and it is behaving pretty well. No more driver or Xpra crashes.

As of r12356 trunk client, it's still working. (Win81)

Passing back to you.

Thu, 14 Apr 2016 04:10:06 GMT - Antoine Martin: status changed; resolution set

status changed from new to closed
resolution set to fixed

Sat, 23 Jan 2021 05:12:00 GMT - migration script:

this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/997