https://bugs.winehq.org/show_bug.cgi?id=37419
Bug ID: 37419 Summary: Zbrush takes 20 minutes to load (better bug report) Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: fleeky@7rnx.net Distribution: ---
Created attachment 49766 --> https://bugs.winehq.org/attachment.cgi?id=49766 log file for zbrush.exe
I made a previous bug report, but did so incorrectly this is my second attempt.
Installed wine 1.7.28 along with all recommended packages. Ran wine with Zbrush.exe without any extra dlls ran the latest development version available from apt-get which is 1.7.28. also am not using any third party wrappers.
Zbrush takes 20 minutes or more to start up, this is not the typical behaviour on windows ( starts up immediately )
Thanks and hopefully this bug report meets your specifications.
https://bugs.winehq.org/show_bug.cgi?id=37419
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|unspecified |1.7.28 Summary|Zbrush takes 20 minutes to |Zbrush takes 20 minutes to |load (better bug report) |load
https://bugs.winehq.org/show_bug.cgi?id=37419
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |performance
https://bugs.winehq.org/show_bug.cgi?id=37419
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW CC| |focht@gmx.net 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 focht@gmx.net --- 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
https://bugs.winehq.org/show_bug.cgi?id=37419
--- Comment #2 from Anastasius Focht focht@gmx.net --- Hello folks,
relevant discussion in Wine-Staging:
https://bugs.wine-staging.com/show_bug.cgi?id=53 ("Use shared memory for wineserver communication")
It would be interesting to have a similar performance test with the small snippet from my analysis converted to real world example (time used for ~8 mio calls of the sequence native vs. Wine).
Regards
https://bugs.winehq.org/show_bug.cgi?id=37419
--- Comment #3 from fleeky fleeky@7rnx.net --- if there are any patches to test out performance i would be more than happy to help test.
https://bugs.winehq.org/show_bug.cgi?id=37419
Sebastian Lackner sebastian@fds-team.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |sebastian@fds-team.de
--- Comment #4 from Sebastian Lackner sebastian@fds-team.de --- (In reply to fleeky from comment #3)
if there are any patches to test out performance i would be more than happy to help test.
Michael Müller is currently working on some patches for shared memory communication to the wineserver, but its too early to share them. He'll update this bug report as soon as its ready and we need testers.
https://bugs.winehq.org/show_bug.cgi?id=37419
--- Comment #5 from Sebastian Lackner sebastian@fds-team.de --- Some patches were added to Wine-Staging. With shared memory wineserver communication enabled (and a recent kernel >= 3.17 with memfd support) some functions are reduced to basically just a couple of memory accesses. For other functions wineserver calls are only done when really necessary. The whole idea is still in a very early stage, and will be improved over the next few versions. Nevertheless it might be worth to test it a bit.
To apply the whole patchset (including dependencies) the easiest way is to check out https://github.com/wine-compholio/wine-staging and use the patchinstall.sh script, it will automatically resolve dependencies between patchsets. Just run from the wine source tree:
.../path/to/patches/patchinstall.sh --backend=git server-Shared_Memory
This function will also run ./tools/make_requests since various updates to the wineserver protocol are required. Afterwards, as soon as the patched version is compiled, run it with STAGING_SHARED_MEMORY=1 set (and probably also WINEDEBUG=+winediag to see if its actually used).
https://bugs.winehq.org/show_bug.cgi?id=37419
--- Comment #6 from fleeky fleeky@7rnx.net --- Created attachment 51108 --> https://bugs.winehq.org/attachment.cgi?id=51108 backtrace errorlog
https://bugs.winehq.org/show_bug.cgi?id=37419
--- Comment #7 from fleeky fleeky@7rnx.net --- so had to reinstal / compile wine from source , then applied patch, now zbrush just crashes? maybe i did something wrong though, not sure
https://bugs.winehq.org/show_bug.cgi?id=37419
--- Comment #8 from Sebastian Lackner sebastian@fds-team.de --- The problem is unrelated to the patch, the app seems to use a different code path now (was there an update?). A native override for vcomp90 should be sufficient, use for example 'winetricks vcrun2008'.
Since you are probably testing with a different version of the app now than the one which used for reporting the bug, make sure to test that the issue is still present with an unpatched version of Wine.
https://bugs.winehq.org/show_bug.cgi?id=37419
Alex boberfly@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |boberfly@gmail.com
--- Comment #9 from Alex boberfly@gmail.com --- Hi,
I'm currently doing some tests here using both the 64-bit and the 32-bit versions of ZBrush 4R7 without much luck.
I'm using 1.8rc2-staging (32-bit and 64-bit) in PlayOnLinux just to keep things easier to test, as well as building my own from 1.8rc3 with only the shared memory staging enabled.
I'm running it with the STAGING_SHARED_MEMORY=1 environment and winediag confirms that it is running.
Unfortunately start-up time is still ridiculous, and I haven't bothered to make it sit there for 20 minutes yet.
While I'm running this, does anyone want anything from me to further debug it?
On the bright side, I think if this polling roundtrip could be worked around, the 64-bit ZBrush version looks like it'll run, fingers crossed!
Also to mention I'm on (K)Ubuntu 15.10 64-bit, which implies a 4.2 Linux kernel with memfd I believe...
https://bugs.winehq.org/show_bug.cgi?id=37419
Daniel Joyce daniel.a.joyce@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |daniel.a.joyce@gmail.com
--- Comment #10 from Daniel Joyce daniel.a.joyce@gmail.com --- ZBrush 4R7 under Wine 1.94 only takes a minute or two to load, vs 30 seconds or so on windows ( I don't have a flash disk and it creates a lot of work/cache files ).
Requirements
1 Wine 1.9.4 2 MFC42 3 vcrun6 4 VC 2008 runtime 5 MS Core Fonts 6 Wine configured to "Emulate a desktop", otherwise startup of Zbrush 4r7 Seems to take quite a bit longer, at least 2-3x as much.
Wine 1.9.5 doesn't appear to be as stable. Web activation seems to hang.
Otherwise, Zbrush 4R7 under wine 1.9.4 seems start up reasonable fast and is stable so far as I have used it.
If its useful, I can capture a wine debug log.
https://bugs.winehq.org/show_bug.cgi?id=37419
winetest@luukku.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |winetest@luukku.com
--- Comment #11 from winetest@luukku.com --- (In reply to Daniel Joyce from comment #10)
6 Wine configured to "Emulate a desktop", otherwise startup of Zbrush 4r7 Seems to take quite a bit longer, at least 2-3x as much.
Wine 1.9.5 doesn't appear to be as stable. Web activation seems to hang.
Otherwise, Zbrush 4R7 under wine 1.9.4 seems start up reasonable fast and is stable so far as I have used it.
If its useful, I can capture a wine debug log.
Debug log would definitely be useful, but most likely some special channels should be used and someone needs to analyze the logs. It's not that easy. It would be also nice to know why it starts faster emulate desktop mode.
I don't know if it helps a bit, but you should try newer wine.
https://bugs.winehq.org/show_bug.cgi?id=37419
hradec me@hradec.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |me@hradec.com
--- Comment #12 from hradec me@hradec.com --- I've just tested ZBrush version 4r7p3 (latest to date) with wine 2.0.
Unfortunately, It's not working at all. Crashes Instantaneously!
this is the backtrace.txt saved the "Program Error details" after the crash:
Unhandled exception: page fault on write access to 0x00000000 in 32-bit code (0x7efc42a7). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP:7efc42a7 ESP:0032eac0 EBP:0032eb38 EFLAGS:00210202( R- -- I - - - ) EAX:00000001 EBX:7efc91fc ECX:00000000 EDX:00000001 ESI:00000000 EDI:00000000 Stack dump: 0x0032eac0: 000000e8 0032ec00 00000010 7bc3fdb3 0x0032ead0: 00000000 00000000 00000018 7bc3feed 0x0032eae0: 00000000 000000e8 0032eb4c 12fae0e0 0x0032eaf0: 0032eb10 7bcda8d0 0032eb68 7bc52e63 0x0032eb00: 00000002 12fae040 0032eb68 7bc52e63 0x0032eb10: 0032ec98 00000000 0032ec00 00000000 Backtrace: =>0 0x7efc42a7 _vcomp_for_static_init+0x247() in vcomp (0x0032eb38) 1 0x05c02f1f in zbrush (+0x5802f1e) (0x0032eb98) 2 0x7efc4bae _vcomp_fork+0x3dd() in vcomp (0x0032ec88) 0x7efc42a7 _vcomp_for_static_init+0x247 in vcomp: movl %edi,0x0(%ecx) Modules: Module Address Debug info Name (128 modules) PE 350000- 35a000 Deferred qgif4 PE 360000- 36b000 Deferred qico4 PE 370000- 3a3000 Deferred qjpeg4 PE 3b0000- 3f8000 Deferred qtiff4 PE 400000- 93c1000 Export zbrush PE dfe0000- e23a000 Deferred memmgr PE e350000- e35a000 Deferred qtwrapper PE e360000- e408000 Deferred avutil-52 PE e520000- e55f000 Deferred swresample-0 PE e670000- e724000 Deferred swscale-2 PE e840000- f8ce000 Deferred avcodec-55 PE f9e0000- f9e7000 Deferred ffmpegwrapper PE fff0000- fff6000 Deferred noiseplugin PE 10000000-101cb000 Deferred fmodex PE 22040000-220e3000 Deferred qtnoiseeditor PE 64000000-640f4000 Deferred qtnetwork4 PE 65000000-657dd000 Deferred qtgui4 PE 67000000-67234000 Deferred qtcore4 PE 78520000-785c3000 Deferred msvcr90 ELF 7b400000-7b7e8000 Deferred kernel32<elf> -PE 7b420000-7b7e8000 \ kernel32 ELF 7bc00000-7bcf8000 Deferred ntdll<elf> -PE 7bc10000-7bcf8000 \ ntdll ELF 7c000000-7c003000 Deferred <wine-loader> ELF 7d27e000-7d308000 Deferred libgmp.so.10 ELF 7d30e000-7d344000 Deferred libhogweed.so.4 ELF 7d346000-7d384000 Deferred libnettle.so.6 ELF 7d386000-7d3ba000 Deferred libidn.so.11 ELF 7d42e000-7d443000 Deferred libtasn1.so.6 ELF 7d446000-7d4a8000 Deferred libp11-kit.so.0 ELF 7d4ae000-7d4e0000 Deferred libcrypt.so.1 ELF 7d4e6000-7d644000 Deferred libgnutls.so.30 ELF 7d646000-7d6cb000 Deferred libcups.so.2 ELF 7d71e000-7d725000 Deferred libxfixes.so.3 ELF 7d726000-7d731000 Deferred libxcursor.so.1 ELF 7d736000-7d73f000 Deferred libffi.so.6 ELF 7d746000-7d77e000 Deferred uxtheme<elf> -PE 7d750000-7d77e000 \ uxtheme ELF 7d786000-7d78d000 Deferred libxdmcp.so.6 ELF 7d78e000-7d792000 Deferred libxau.so.6 ELF 7d796000-7d7c1000 Deferred libxcb.so.1 ELF 7d7c6000-7d915000 Deferred libx11.so.6 ELF 7d916000-7d92b000 Deferred libxext.so.6 ELF 7d92e000-7d941000 Deferred libxi.so.6 ELF 7d946000-7d94a000 Deferred libxcomposite.so.1 ELF 7d94e000-7d95b000 Deferred libxrandr.so.2 ELF 7d95e000-7d96a000 Deferred libxrender.so.1 ELF 7d96e000-7d975000 Deferred libxxf86vm.so.1 ELF 7d976000-7d97a000 Deferred libxinerama.so.1 ELF 7d97e000-7da0f000 Deferred winex11<elf> -PE 7d990000-7da0f000 \ winex11 ELF 7da16000-7da3b000 Deferred imm32<elf> -PE 7da20000-7da3b000 \ imm32 ELF 7db56000-7db80000 Deferred libexpat.so.1 ELF 7db86000-7dbd0000 Deferred libfontconfig.so.1 ELF 7dbd6000-7dc4f000 Deferred libpcre.so.1 ELF 7dc56000-7dd7d000 Deferred libglib-2.0.so.0 ELF 7dd7e000-7ddfe000 Deferred libharfbuzz.so.0 ELF 7ddfe000-7de3c000 Deferred libpng16.so.16 ELF 7de3e000-7de4f000 Deferred libbz2.so.1.0 ELF 7de56000-7df18000 Deferred libfreetype.so.6 ELF 7df6e000-7dfb1000 Deferred winspool<elf> -PE 7df80000-7dfb1000 \ winspool ELF 7dfb6000-7e0c2000 Deferred comctl32<elf> -PE 7dfc0000-7e0c2000 \ comctl32 ELF 7e0c6000-7e1b6000 Deferred comdlg32<elf> -PE 7e0d0000-7e1b6000 \ comdlg32 ELF 7e1b6000-7e275000 Deferred msvcrt<elf> -PE 7e1d0000-7e275000 \ msvcrt ELF 7e276000-7e330000 Deferred winmm<elf> -PE 7e280000-7e330000 \ winmm ELF 7e336000-7e34f000 Deferred libresolv.so.2 ELF 7e356000-7e371000 Deferred wsock32<elf> -PE 7e360000-7e371000 \ wsock32 ELF 7e376000-7e3a2000 Deferred msacm32<elf> -PE 7e380000-7e3a2000 \ msacm32 ELF 7e3a6000-7e3ce000 Deferred iphlpapi<elf> -PE 7e3b0000-7e3ce000 \ iphlpapi ELF 7e3ce000-7e40b000 Deferred ws2_32<elf> -PE 7e3e0000-7e40b000 \ ws2_32 ELF 7e40e000-7e65e000 Deferred shell32<elf> -PE 7e420000-7e65e000 \ shell32 ELF 7e65e000-7e686000 Deferred mpr<elf> -PE 7e660000-7e686000 \ mpr ELF 7e686000-7e69f000 Deferred libz.so.1 ELF 7e6a6000-7e723000 Deferred wininet<elf> -PE 7e6b0000-7e723000 \ wininet ELF 7e726000-7e7ac000 Deferred rpcrt4<elf> -PE 7e730000-7e7ac000 \ rpcrt4 ELF 7e7ae000-7e8f6000 Deferred ole32<elf> -PE 7e7d0000-7e8f6000 \ ole32 ELF 7e8f6000-7e972000 Deferred advapi32<elf> -PE 7e900000-7e972000 \ advapi32 ELF 7e976000-7eaac000 Deferred gdi32<elf> -PE 7e980000-7eaac000 \ gdi32 ELF 7eaae000-7ec0f000 Deferred user32<elf> -PE 7eac0000-7ec0f000 \ user32 ELF 7ec16000-7ec91000 Deferred shlwapi<elf> -PE 7ec20000-7ec91000 \ shlwapi ELF 7ec96000-7ed27000 Deferred gdiplus<elf> -PE 7ecb0000-7ed27000 \ gdiplus ELF 7ef2e000-7ef41000 Deferred libnss_files.so.2 ELF 7ef46000-7ef9b000 Deferred libm.so.6 ELF 7ef9e000-7efa7000 Deferred librt.so.1 ELF 7efae000-7efcb000 Dwarf vcomp<elf> -PE 7efb0000-7efcb000 \ vcomp ELF 7efce000-7efe3000 Deferred vcomp90<elf> -PE 7efd0000-7efe3000 \ vcomp90 ELF 7efe6000-7efff000 Deferred version<elf> -PE 7eff0000-7efff000 \ version ELF f644e000-f6594000 Deferred oleaut32<elf> -PE f6470000-f6594000 \ oleaut32 ELF f6596000-f66fa000 Deferred msvcp90<elf> -PE f65e0000-f66fa000 \ msvcp90 ELF f66fe000-f68bd000 Deferred libcrypto.so.1.0.0 ELF f68be000-f6917000 Deferred libssl.so.1.0.0 ELF f691e000-f6977000 Deferred libldap_r-2.4.so.2 ELF f69ce000-f6a32000 Deferred wldap32<elf> -PE f69e0000-f6a32000 \ wldap32 ELF f7256000-f7269000 Deferred psapi<elf> -PE f7260000-f7269000 \ psapi ELF f7396000-f739b000 Deferred libdl.so.2 ELF f739e000-f7557000 Deferred libc.so.6 ELF f755e000-f757b000 Deferred libpthread.so.0 ELF f758e000-f759e000 Deferred liblber-2.4.so.2 ELF f75ce000-f7785000 Dwarf libwine.so.1 ELF f7786000-f77aa000 Deferred ld-linux.so.2 ELF f77b1000-f77b2000 Deferred [vdso].so Threads: process tid prio (all id:s are in hex) 00000008 (D) C:\Program Files\Pixologic\ZBrush 4R7\ZBrush.exe 00000030 0 0000002f 0 0000002e 0 0000002d 0 0000002c 0 0000002b 0 0000002a 0 00000009 0 <== 0000000e services.exe 00000020 0 0000001f 0 00000014 0 00000010 0 0000000f 0 00000012 winedevice.exe 0000001e 0 00000019 0 00000018 0 00000013 0 0000001c plugplay.exe 00000022 0 00000021 0 0000001d 0 00000023 explorer.exe 00000029 0 00000028 0 00000027 0 00000026 0 00000025 0 00000024 0 System information: Wine build: wine-2.0 Platform: i386 Version: Windows 7 Host system: Linux Host version: 4.7.1-1-ARCH
I can confirm though that version 1.9.4 STILL works with this latest version of zbrush, though!
If you need more info/logs/debug/etc, plz let me known!!
-H
https://bugs.winehq.org/show_bug.cgi?id=37419
--- Comment #13 from Austin English austinenglish@gmail.com --- (In reply to hradec from comment #12)
I can confirm though that version 1.9.4 STILL works with this latest version of zbrush, though!
If you need more info/logs/debug/etc, plz let me known!!
Could you run a regression test (between 1.9.4 and 2.0)? https://wiki.winehq.org/RegressionTesting
https://bugs.winehq.org/show_bug.cgi?id=37419
--- Comment #14 from Sebastian Lackner sebastian@fds-team.de --- (In reply to Austin English from comment #13)
(In reply to hradec from comment #12)
I can confirm though that version 1.9.4 STILL works with this latest version of zbrush, though!
If you need more info/logs/debug/etc, plz let me known!!
Could you run a regression test (between 1.9.4 and 2.0)? https://wiki.winehq.org/RegressionTesting
There is no regression test needed, vcomp90 was changed from "prefer native" to "prefer builtin" in commit 0c824225ad19b1647959dafefc4515440d3cce04. Manually setting to "native" would probably still work, but of course we also want to fix the real issue.
@hradec: Could you please open a new bug report and add me as CC?
https://bugs.winehq.org/show_bug.cgi?id=37419
--- Comment #15 from Daniel Joyce daniel.a.joyce@gmail.com --- Can confirm. If I go into winecfg and add a library override telling it to only use native for vcomp90, Zbrush64 on Wine64 2.0-RC3 starts normally! :D
Will try 2.0-rc6 or whatever is lastest later.
Startup is still a little slow, but it seems to be mostly setting up a cache file.
https://bugs.winehq.org/show_bug.cgi?id=37419
--- Comment #16 from Alex boberfly@gmail.com --- As a follow-up, I've tried again with PlayOnLinux with Wine 1.9.4-staging and followed Daniel Joyce's steps exactly.
Having an emulated desktop _really_ helps! The startup time of 64-bit ZBrush is now about the same as Windows, maybe slightly slower but not by much! I've not dared to try 2.1 quite yet as it is working fine now but I will try eventually. My Intuos works well with pressure sensitivity also.
I've been running (K)Ubuntu 16.04 64-bit as well this time around.
Cheers
https://bugs.winehq.org/show_bug.cgi?id=37419
Jimmy Christensen lithorus@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |lithorus@gmail.com
--- Comment #17 from Jimmy Christensen lithorus@gmail.com --- @Alex Does pen pressure still work after you have saved the scene (or autosave) in zbrush?
https://bugs.winehq.org/show_bug.cgi?id=37419
--- Comment #18 from Daniel Joyce daniel.a.joyce@gmail.com --- (In reply to Jimmy Christensen from comment #17)
@Alex Does pen pressure still work after you have saved the scene (or autosave) in zbrush?
Yes. It seems to work fine. Even supports my old wacom under linux perfectly while windows 10 no longer supports it.
Would it be possible to fast-track the keyboard state requests somehow? Memoize them so the actual state is only updated say every 15ms ( approx 50wpm) and if the calls come faster than that, just return a cached value instead of polling the actual kbd state?
It just doesn't make sense to have the polling code execute the full code path at a rate far faster than people can type.
Shoot, I might try that myself if someone can tell me where to look
https://bugs.winehq.org/show_bug.cgi?id=37419
Anton Romanov theli.ua@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |theli.ua@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=37419
Neko-san nekoNexus@protonmail.ch changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |nekoNexus@protonmail.ch
-
wine-bugs＠winehq.org -
WineHQ Bugzilla