December 2025 - Wine-GitLab

[PATCH v4 0/2] MR7938: Draft: winemac: Use IOSurface to update native window layers instead of CGImage.
by Marc-Aurel Zent (＠mzent) Dec. 4, 2025

Dec. 4, 2025

This consolidates the two separate `CGImage`s (`colorImage` and `shapeImage`) previously used in `WineContentView` into a single `IOSurface` that also holds the window mask information in its alpha channel now. The alpha channel is now being updated in `macdrv_surface_flush`, whenever the shape changes (and stores that change for the next update, to also keep the front buffer in sync). This reduces the delay from setting a `CGImage` to a layer from 50ms to about 1.5ms in the `IOSurface` case (also accounting for `vImageSelectChannels_ARGB8888` operation). Based on a patch by @bshanks. I am already putting it out for feedback, but I will so some more testing to see how the performance impact of this is and do more exhaustive testing with shaped windows. Ideally the double buffer solution can be avoided as well... Also the `HBITMAP` for the windows is currently backed by a `CGDataProviderRef` and could also become an `IOSurface` I believe. -- v4: winemac: Use IOSurface to update native window layers instead of CGImage. https://gitlab.winehq.org/wine/wine/-/merge_requests/7938

2 4

[PATCH 0/1] MR9677: opengl32: Cleanup glGet* and fix typo in glGetDoublev.
by Rémi Bernon Dec. 4, 2025

Dec. 4, 2025

Signed-off-by: Derek Lesho <dlesho(a)codeweavers.com> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9677

2 2

[PATCH v3 0/2] MR7938: Draft: winemac: Use IOSurface to update native window layers instead of CGImage.
by Marc-Aurel Zent (＠mzent) Dec. 4, 2025

Dec. 4, 2025

This consolidates the two separate `CGImage`s (`colorImage` and `shapeImage`) previously used in `WineContentView` into a single `IOSurface` that also holds the window mask information in its alpha channel now. The alpha channel is now being updated in `macdrv_surface_flush`, whenever the shape changes (and stores that change for the next update, to also keep the front buffer in sync). This reduces the delay from setting a `CGImage` to a layer from 50ms to about 1.5ms in the `IOSurface` case (also accounting for `vImageSelectChannels_ARGB8888` operation). Based on a patch by @bshanks. I am already putting it out for feedback, but I will so some more testing to see how the performance impact of this is and do more exhaustive testing with shaped windows. Ideally the double buffer solution can be avoided as well... Also the `HBITMAP` for the windows is currently backed by a `CGDataProviderRef` and could also become an `IOSurface` I believe. -- v3: winemac: Use IOSurface to update native window layers instead of CGImage. winemac: Also return alpha channel in macdrv_window_background_color. https://gitlab.winehq.org/wine/wine/-/merge_requests/7938

2 6

[PATCH 0/4] MR9676: win32u: Query EGL devices UUID with EGL_EXT_device_persistent_id.
by Rémi Bernon Dec. 4, 2025

Dec. 4, 2025

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

1 4

Re: [PATCH v2 0/3] MR9585: win32u: Introduce a D3DKMT escape code to set fullscreen present rect. (1/2)
by Rémi Bernon Dec. 4, 2025

Dec. 4, 2025

> Er, right, I meant the video present node source ID, that's the monitor as I understand. Maybe, but in any case we don't have a proper implementation of those anyway. > Well, the point is, it's always going to be the full monitor, isn't it? Perhaps, but I don't think it really matters as this is a custom and probably a temporary mechanism. Ultimately we might want to do things differently but here I'm only aiming at something simple that works for Wine 11, not something perfect that will take time to design properly. We have the rect at hand, while getting a monitor would require something more complicated possibly with more unforeseen issues. > Right, we also need that call. I think it's still better arrangement to have calls in those three places. Sure, changed it to this. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9585#note_124659

1 0

[PATCH 0/1] MR9675: winemac: Avoid taking the window lock when creating client surface.
by Rémi Bernon Dec. 4, 2025

Dec. 4, 2025

It's not even necessary anymore, and macdrv_create_view blocks on the main thread, which sometimes seems to trigger a deadlock. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9675

1 1

[PATCH 0/1] MR9672: win32u: Don't alter memory beyond structure effective size in NtUserEnumDisplaySettings().
by Paul Gofman (＠gofman) Dec. 4, 2025

Dec. 4, 2025

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

3 3

[PATCH 0/4] MR9674: PDB speedup 2
by eric pouech (＠epo) Dec. 4, 2025

Dec. 4, 2025

Continuing PDB reading optimizations: - optimize DBI hash table (150ms gained in ref test) - optimize compiland selection in line information queries (can be several hundreds of ms) moving from a linear to a binary search. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9674

2 4

[PATCH 0/4] MR9661: opengl32: Get OpenGL function table on process attach.
by Rémi Bernon Dec. 4, 2025

Dec. 4, 2025

Allowing win32u to use the OpenGL function table without requiring opengl32 module initialization. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9661

2 5

[PATCH 0/1] MR9663: Draft: winecoreaudio: Set the AudioChannelLayout on output units.
by Brendan Shanks (＠bshanks) Dec. 4, 2025

Dec. 4, 2025

Some users have reported the center/LFE channels being swapped when playing games that support surround sound. After investigating, it appears that winecoreaudio never sets AudioChannelLayout on the audio unit, and assumes that it matches the Windows layout (which is the order of `dwChannelMask`). This is often true, but not always. Using some test code [1] in `ca_setup_audiounit()` to get the AudioChannelLayout (Dell U2711 over HDMI), for some reason the audio unit defaults to having the center (3) and LFE (4) positions swapped from where Windows lays them out: ``` 1389548.056:0020:0124:err:coreaudio:ca_setup_audiounit Got channel layout: {tag: 0x0, bitmap: 0x0, num_descs: 6} 1389548.056:0020:0124:err:coreaudio:ca_setup_audiounit desc 0: label 1 flags 0 1389548.056:0020:0124:err:coreaudio:ca_setup_audiounit desc 1: label 2 flags 0 1389548.056:0020:0124:err:coreaudio:ca_setup_audiounit desc 2: label 4 flags 0 1389548.056:0020:0124:err:coreaudio:ca_setup_audiounit desc 3: label 3 flags 0 1389548.056:0020:0124:err:coreaudio:ca_setup_audiounit desc 4: label 5 flags 0 1389548.056:0020:0124:err:coreaudio:ca_setup_audiounit desc 5: label 6 flags 0 ``` To fix this, set the AudioChannelLayout in `ca_setup_audiounit()`. Happily the Core Audio `AudioChannelBitmap` and Windows `dwChannelMask` perfectly match each other in speaker/bit positions, so this is easy. Marked as draft pending some extra testing. [1]: ``` { UInt32 size; Boolean writable; sc = AudioUnitGetPropertyInfo(unit, kAudioUnitProperty_AudioChannelLayout, kAudioUnitScope_Output, 0, &size, &writable); ERR("AudioChannelLayout sc %d\n", sc); if (sc == noErr) { AudioChannelLayout *layout = malloc(size); sc = AudioUnitGetProperty(unit, kAudioUnitProperty_AudioChannelLayout, kAudioUnitScope_Output, 0, layout, &size); ERR("AudioChannelLayout 2 sc %d\n", sc); ERR("Got channel layout: {tag: 0x%x, bitmap: 0x%x, num_descs: %u}\n", (unsigned int)layout->mChannelLayoutTag, (unsigned int)layout->mChannelBitmap, (unsigned int)layout->mNumberChannelDescriptions); for (unsigned int i = 0; i < layout->mNumberChannelDescriptions; i++) { ERR("desc %d: label %d flags %x\n", i, layout->mChannelDescriptions[i].mChannelLabel, layout->mChannelDescriptions[i].mChannelFlags); } free(layout); } } } ``` -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9663

3 2