- Wine-gitlab - list.winehq.org

[PATCH 0/1] MR10057: d2d1: Forward geometry group methods to the path representing the group.
by Nikolay Sivov (＠nsivov) 09 Feb '26

09 Feb '26

Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10057

2 1

[PATCH 0/1] MR10054: mf: Don't perform preroll if we are scrubbing.
by Brendan McGrath (＠redmcg) 09 Feb '26

09 Feb '26

Tests on Windows show that a preroll isn't requested by the media session if rate is zero. This MR changes media session to match that behaviour. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10054

3 2

[PATCH 0/2] MR10053: mf: Fix crash when stream is null during sample request.
by Brendan McGrath (＠redmcg) 09 Feb '26

09 Feb '26

Windows waits until it receives the MEStreamStarted event(s) before subscribing to the sink event queues. This is the successor to MR !9716. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10053

3 3

Re: [PATCH v7 0/6] MR10039: comctl32: Fix the bug when the cInitial is too large which lead to CreateDIBSection fails. - closed
by Kun Yang (＠yangkun) 09 Feb '26

09 Feb '26

This merge request was closed by Kun Yang. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10039

1 0

[PATCH v6 0/6] MR10039: comctl32: Fix the bug when the cInitial is too large which lead to CreateDIBSection fails.
by Kun Yang (＠yangkun) 09 Feb '26

09 Feb '26

When I was porting a software from windows, I met a problem that the icons in the imagelist were not displaying correctly. In the Application, the correct icons are: ![1](/uploads/9d474b7fa9447c9ff7ada8515a4dc07b/1.bmp){width=269 height=29} But when I run it under wine is like this: ![2](/uploads/8b69186797c6e3542fe371ff6c4f6b0a/2.bmp){width=271 height=29} When I disassable the application code I found that the Application calls ImageList_Create by given a very large cInitial, which is 0xc0c0c0. This will lead to CreateDIBSection fail. Then the source hbitmap is lost, only hMask is left and shown up on the screen. I use windbg to debug this application on windows, I found that after ImageList_Create is called on Winodws, there is a valid hbitmap handle generated. When ImageList_Add is called for 4 times, it changed and called Bitblt to copy the hbitmap already added. So I guess windows has the error handling for ImageList_Create. If CreateDIBSection failes due to the large image count, it reduced the image count. By observing the action in ImageList_Add, I think the reduced count is 1 (4x1). Then fix the cMaxImage to 1+1 which is same as ImageListImpl_Initialize to make the hbitmap expand. The example in the attachment can reproduce this bug. [imagelist.7z](/uploads/b5f7013fa9383c00bbbc38f82383ff1a/imagelist.7z) -- v6: comctl32: Fix the bug when the cInitial is too large which lead to CreateDIBSection fails. https://gitlab.winehq.org/wine/wine/-/merge_requests/10039

2 7

[PATCH v5 0/5] MR10039: comctl32: Fix the bug when the cInitial is too large which lead to CreateDIBSection fails.
by Kun Yang (＠yangkun) 09 Feb '26

09 Feb '26

When I was porting a software from windows, I met a problem that the icons in the imagelist were not displaying correctly. In the Application, the correct icons are: ![1](/uploads/9d474b7fa9447c9ff7ada8515a4dc07b/1.bmp){width=269 height=29} But when I run it under wine is like this: ![2](/uploads/8b69186797c6e3542fe371ff6c4f6b0a/2.bmp){width=271 height=29} When I disassable the application code I found that the Application calls ImageList_Create by given a very large cInitial, which is 0xc0c0c0. This will lead to CreateDIBSection fail. Then the source hbitmap is lost, only hMask is left and shown up on the screen. I use windbg to debug this application on windows, I found that after ImageList_Create is called on Winodws, there is a valid hbitmap handle generated. When ImageList_Add is called for 4 times, it changed and called Bitblt to copy the hbitmap already added. So I guess windows has the error handling for ImageList_Create. If CreateDIBSection failes due to the large image count, it reduced the image count. By observing the action in ImageList_Add, I think the reduced count is 1 (4x1). Then fix the cMaxImage to 1+1 which is same as ImageListImpl_Initialize to make the hbitmap expand. The example in the attachment can reproduce this bug. [imagelist.7z](/uploads/b5f7013fa9383c00bbbc38f82383ff1a/imagelist.7z) -- v5: comctl32: Fix the bug when the cInitial is too large which lead to CreateDIBSection fails. https://gitlab.winehq.org/wine/wine/-/merge_requests/10039

2 5

[PATCH v4 0/4] MR10039: comctl32: Fix the bug when the cInitial is too large which lead to CreateDIBSection fails.
by Kun Yang (＠yangkun) 09 Feb '26

09 Feb '26

When I was porting a software from windows, I met a problem that the icons in the imagelist were not displaying correctly. In the Application, the correct icons are: ![1](/uploads/9d474b7fa9447c9ff7ada8515a4dc07b/1.bmp){width=269 height=29} But when I run it under wine is like this: ![2](/uploads/8b69186797c6e3542fe371ff6c4f6b0a/2.bmp){width=271 height=29} When I disassable the application code I found that the Application calls ImageList_Create by given a very large cInitial, which is 0xc0c0c0. This will lead to CreateDIBSection fail. Then the source hbitmap is lost, only hMask is left and shown up on the screen. I use windbg to debug this application on windows, I found that after ImageList_Create is called on Winodws, there is a valid hbitmap handle generated. When ImageList_Add is called for 4 times, it changed and called Bitblt to copy the hbitmap already added. So I guess windows has the error handling for ImageList_Create. If CreateDIBSection failes due to the large image count, it reduced the image count. By observing the action in ImageList_Add, I think the reduced count is 1 (4x1). Then fix the cMaxImage to 1+1 which is same as ImageListImpl_Initialize to make the hbitmap expand. The example in the attachment can reproduce this bug. [imagelist.7z](/uploads/b5f7013fa9383c00bbbc38f82383ff1a/imagelist.7z) -- v4: comctl32: Fix the bug when the cInitial is too large which lead to CreateDIBSection fails. https://gitlab.winehq.org/wine/wine/-/merge_requests/10039

2 4

Re: [PATCH v9 0/34] MR9928: Draft: dsound: Speed up resampling.
by Anton Baskanov (＠baskanov) 09 Feb '26

09 Feb '26

v9: - Add zero padding at the ends of the FIR. This is required for correct linear interpolation. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9928#note_129130

1 0

[PATCH v8 0/34] MR9928: Draft: dsound: Speed up resampling.
by Anton Baskanov (＠baskanov) 09 Feb '26

09 Feb '26

This implements a number of optimizations, in particular: - Swapping around the resampling loops in case of downsampling, allowing the FIR step to stay fixed regardless of the resampling ratio. - Rearranging the FIR array elements to make the access sequential. - Adding SSE versions of the resampling functions. Together, these amount to more than a 5x reduction of `cp_fields_resample` execution time. The quality of the resampling should be the same, or even improve slightly, due to a more precise `rem` calculation and removal of the FIR step rounding, although I haven't yet conducted any measurements. **UPDATE** Added some more optimizations: - Using fixed point math inside the resampling functions. - Optimizing the SSE versions by hand. - Adding AVX+FMA3 versions of the resampling functions. - Getting and putting all channel samples in one go. Combined with the previous ones, these bring the total speedup to 15x for upsampling and 13x for downsampling compared to the upstream. -- v8: dsound: Initialize freqAccNum to freqAdjustDen / 2. This merge request has too many patches to be relayed via email. Please visit the URL below to see the contents of the merge request. https://gitlab.winehq.org/wine/wine/-/merge_requests/9928

1 1

Re: [PATCH v7 0/34] MR9928: Draft: dsound: Speed up resampling.
by Anton Baskanov (＠baskanov) 09 Feb '26

09 Feb '26

v7: - Fix `mixpos` calcluation. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9928#note_129124

1 0