[Bug 37419] Pixologic Zbrush 4R5/4R6 takes 20 minutes to load (polling via GetForegroundWindow/GetAsyncKeyState involving wineserver roundtrip too slow)

https://bugs.winehq.org/show_bug.cgi?id=37419

Anastasius Focht  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
                 CC|                            |[e-mail]
            Summary|Zbrush takes 20 minutes to  |Pixologic Zbrush 4R5/4R6
                   |load                        |takes 20 minutes to load
                   |                            |(polling via
                   |                            |GetForegroundWindow/GetAsyn
                   |                            |cKeyState involving
                   |                            |wineserver roundtrip too
                   |                            |slow)
     Ever confirmed|0                           |1

--- Comment #1 from Anastasius Focht  ---
Hello folks,

confirming. I found a distributed backup of Pixologic Zbrush 4R6 to play with.

--- snip ---
$ pwd
/home/focht/.wine/drive_c/Program Files/Pixologic/ZBrush 4R6
...
$ WINEDEBUG=+tid,+seh,+relay wine ./ZBrush.exe >>log2.txt 2>&1
...
0029:Call user32.GetForegroundWindow() ret=043ce222
0029:Ret  user32.GetForegroundWindow() retval=00010072 ret=043ce222
0029:Call user32.GetAsyncKeyState(0000001b) ret=043ce235
0029:Call
winex11.drv.MsgWaitForMultipleObjectsEx(00000000,00000000,00000000,00000407,00000000)
ret=7ebab123
0029:Ret  winex11.drv.MsgWaitForMultipleObjectsEx() retval=00000102
ret=7ebab123
0029:Ret  user32.GetAsyncKeyState() retval=00000000 ret=043ce235
0029:Call user32.GetCursorPos(0033d66c) ret=043ce801
0029:Call winex11.drv.GetCursorPos(0033d66c) ret=7ebaacfa
0029:Ret  winex11.drv.GetCursorPos() retval=00000001 ret=7ebaacfa
0029:Ret  user32.GetCursorPos() retval=00000001 ret=043ce801
0029:Call user32.ClientToScreen(00010072,0033d664) ret=043ce81d
0029:Ret  user32.ClientToScreen() retval=00000001 ret=043ce81d 
...
--- snip ---

The app makes a huge number of keyboard polling requests during startup.
It basically checks if the foreground window is the main window and then
retrieves the key state.

--- snip ---
...
043CE21C   FF15 4CB36204   CALL DWORD PTR DS:[<&USER32.GetForegroundWindow>]
043CE222   3B05 A8833805   CMP EAX,DWORD PTR DS:[53883A8]
043CE228   74 03           JE SHORT ZBrush.043CE22D
043CE22A   32C0            XOR AL,AL
043CE22C   C3              RETN
043CE22D   6A 1B           PUSH 1B
043CE22F   FF15 50B36204   CALL DWORD PTR DS:[<&USER32.GetAsyncKeyState>]
043CE235   98              CWDE
043CE236   C1E8 1B         SHR EAX,1B
043CE239   83E0 01         AND EAX,1
043CE23C   C3              RETN 
...
--- snip ---

Some "genius" put the sequence shown above (and variations) at several places
in the core of the app's own scripting engine in order to implement 'cancel'
capability via user input.

On startup, several complex built-in scripts get executed, resulting in
millions of script engine calls.

I measured around 8 million(!) calls to 'GetForegroundWindow' which includes
wineserver roundtrip.
If you have the focus on main window (default) add another 8 million calls to
'GetAsyncKeyState' which includes wineserver roundtrip.

Windows doesn't have this heavy penalty on both API due to different design.

Without a client side caching or "shared user data" (shmem) approach, which
avoids the costly wineserver roundtrip there is not much that can be done here.

Some stupid app behaviour can't be fixed easily. These guys probably never
heard of raw input model.

Bug 29582 is about a similar issue.

$ du -sh ZBrush_4R6_Installer_WIN.exe 
698M    ZBrush_4R6_Installer_WIN.exe

$ sha1sum ZBrush_4R6_Installer_WIN.exe 
8b9c3743160c9272b75f6f5511422481b91d8bf7  ZBrush_4R6_Installer_WIN.exe

$ wine --version
wine-1.7.29-76-g4bb80af

Regards