May 2024 - wine-gitlab

[PATCH 0/3] MR5474: winhttp: Receive response timeout and connection caching.
by Paul Gofman (＠gofman) 28 May '24

28 May '24

-- https://gitlab.winehq.org/wine/wine/-/merge_requests/5474

3 5

[PATCH v5 0/3] MR5464: mf/tests: Check that D3D aware attribute has no effect on the topology.
by Rémi Bernon (＠rbernon) 28 May '24

28 May '24

Wine incorrectly inserts a sample copier. D3D awareness is handled per node, and each node will have their own sample allocator created from the D3D device manager provided by the session. -- v5: mf/tests: Test device manager handling in the topology loader. mf/tests: Test D3D awareness handling in the topology loader. include: Add MFTOPOLOGY_DXVA_MODE enum definition. https://gitlab.winehq.org/wine/wine/-/merge_requests/5464

3 8

[PATCH v2 0/2] MR2724: wined3d: Submit command buffers that are built for longer than 2 ms.
by Zebediah Figura (＠zfigura) 28 May '24

28 May '24

This improves performance for the game "Grounded", on a AMD Radeon RX 6700 XT, with radv from Mesa 22.3.6. Testing was done with the "cb_access_map_w" option enabled, which also improves performance with the game by itself. From my testing, it's possible to raise the threshold from 2 ms up to 5 ms or so, before the driver or GPU seems to reclock back to the lower power level. However, this measurement is questionable for several reasons. It seems to vary depending on the scene being rendered, and of course this will be specific to the game and driver and GPU in question anyway. The game also has a weird approach to vsync that seems to involve it presenting stale frames (and hence artificially inflating the FPS), which I'm not fully sure I accounted for while measuring. And of course, it's hard to be sure that 5 ms is actually the threshold for how long the driver will go before powering down the GPU. In any case, it seems better to err on the side of submitting more often, to make sure the fix affects more drivers. While submission isn't cheap, it seems to me that submitting every 2 ms is unlikely to cause a bottleneck [consider that this is at most 8 (more) submissions per frame]. The maximum of 4 concurrent periodically submitted buffers was chosen arbitrarily. Removing the maximum altogether does not measurably affect performance for this game either way. Credit goes to Philip Rebohle and his work on DXVK for helping me to notice that periodic submission might make a difference. -- v2: wined3d: Submit command buffers that are built for longer than 2 ms. wined3d: Retrieve the VkCommandBuffer from wined3d_context_vk after executing RTV barriers. https://gitlab.winehq.org/wine/wine/-/merge_requests/2724

7 15

[PATCH 0/4] MR5458: widl: Add support for interfaces to SLTG typelib generator.
by Dmitry Timoshkov (＠dmitry) 28 May '24

28 May '24

Adding support for interfaces implies adding support for function descriptions, so the patch is a bit large. I didn't manage to create an .idl with a function outside of an interface, so I couldn't test it separately. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5458

4 7

[PATCH 0/2] MR5454: winegstreamer: Ensure stream format change notification on size change in h264 decoder.
by Paul Gofman (＠gofman) 28 May '24

28 May '24

-- https://gitlab.winehq.org/wine/wine/-/merge_requests/5454

4 10

[PATCH v6 0/1] MR5188: Draft: winemac.drv: Hide app's dock icon when it wouldn't have a taskbar item on Windows.
by Tim Clem (＠tclem) 28 May '24

28 May '24

This is a change from the default behavior in macdrv for as long as it's existed, as far as I can tell. Previously, gaining a dock icon was a one-way path. However, that doesn't jive with the way taskbar entries work on Windows; if an app has no windows, it doesn't appear in the taskbar. This patch attempts to remedy cases where an app winds up with superfluous dock icons for exe's that no longer have windows (looking at you, basically every launcher and Steam). The major concern I can see with this is that if an app closes all of its windows but does not exit, there will be no indication that it is still running. Two thoughts on that: 1. That *should* be an anomalous case, such as the app hanging on exit. 2. Effectively the same behavior would happen on Windows. I would love to hear any other thoughts about this change. I'm open (though I would not prefer it) to defaulting the registry key to false if that would alleviate any concerns. -- v6: winemac.drv: Hide app's dock icon when it wouldn't have a taskbar item on Windows. https://gitlab.winehq.org/wine/wine/-/merge_requests/5188

2 2

Re: [PATCH v2 0/1] MR5447: fonts: Add U+FF0B U+25BC U+2715, fix visual issue in Notepad++
by Loïc Rebmeister (＠Fox2Code) 28 May '24

28 May '24

On Sun Apr 7 09:32:45 2024 +0000, Sam Joan Roque-Worcel wrote: > Hmm I thought the tests I was getting were flakey, but it seems that my > changes here are causing failing tests. I may ask in IRC if anyone can > think of a better approach. I don't see why adding them only to a new MS Gothic font stub with only 3 symbol wouldn't work? If peoples add the real MS Gothic everything should work fine, there is no reason for it to not work. Especially since most peoples use `winetricks` and it's already used to override existing stub fonts. Adding to Tahoma seems fine as a workaround because Tahoma doesn't have those, but upstream isn't a fan of MR that push wine away from Win32 like behavior, so it may delay this being merged. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5447#note_67258

1 0

[PATCH 0/6] MR5470: win32u: Get rid of the window surface recursive mutex.
by Rémi Bernon (＠rbernon) 28 May '24

28 May '24

-- https://gitlab.winehq.org/wine/wine/-/merge_requests/5470

3 8

Re: [PATCH v4 0/5] MR5464: mf/tests: Check that D3D aware attribute has no effect on the topology.
by Rémi Bernon (＠rbernon) 28 May '24

28 May '24

I see, and indeed the presence of a device manager exposed through the sink services apparently changes something. I'll add some more tests for that. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5464#note_67253

1 0

Re: [PATCH v4 0/5] MR5464: mf/tests: Check that D3D aware attribute has no effect on the topology.
by Nikolay Sivov (＠nsivov) 28 May '24

28 May '24

I don't know how much this test actually shows. Device manager is provided by the sink. Topology loader then is documented to set this device manager to the transforms on the video branch. There is MF_TOPOLOGY_DXVA_MODE attribute that supposedly controls that. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5464#note_67239

1 0

2025

2024

2023

2022

wine-gitlab May 2024