--
v4: dmsynth/tests: Test DirectMusicSynth class in isolation.
dmsynth/tests: Test DirectMusicSynthSink class in isolation.
dmsynth/tests: Import and use a check_interface helper.
dmsynth/tests: Avoid dynamic format string.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3675
The problem is that registry save is a very heavy operation (scheduled each 30sec in wineserver) during which server doesn't process any requests and the whole prefix is stalled for the duration of the operation.
For some reference, the process takes from 50-100ms here up to 1-1.5sec with default initial registry (after some registry modifications which trigger actual registry flush), depending on the filesystem type and state (as huge time may be spent in file close / rename). With the same registry after this patchset the server part (flush_key returning the whole registry data) is taking ~4-5mcs, measured from the client side so that already includes data transfer.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3124
At least Doom 64 calls ClipCursor() with identical parameters
repeatedly, which seems to cause a considerable overhead. Together with
high polling rate mouse input this causes the game to almost freeze
while the mouse is being moved. So if the clipping did not change we can
bail out early because it will not cause any observable difference
anyway.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=46976
Signed-off-by: Jan Klötzke <jan(a)kloetzke.net>
--
v2: winex11.drv: optimize repeated ClipCursor calls
winex11.drv: create win32 clipping window only once
https://gitlab.winehq.org/wine/wine/-/merge_requests/825
This simplifies future tests that check for object name of devices.
--
v2: server: Fix object name resolution of \Device\Null.
server: Make explicit the ownership of the unix_name buffer.
https://gitlab.winehq.org/wine/wine/-/merge_requests/475