June 2025 - Wine-Devel - list.winehq.org

Re: Does the timing of composition need to be moved from dcomp.dll to win32u?

by Zhiyi Zhang

On 6/19/25 14:13, zhengxianwei wrote: > Zhiyi Zhang provided an implementation of DComp composition： > https://gitlab.winehq.org/zhiyi/wine/-/commit/ef4f90c2ae909f4a732f0ebeae3b7… <https://gitlab.winehq.org/zhiyi/wine/-/commit/ef4f90c2ae909f4a732f0ebeae3b7…> > > I created a simple sample that renders three equally sized red circles with varying alpha values on a plain white background window. > > On Windows, it displays as follows. > > dcomp_test_window.png > > But on Linux, it display as follows. > dcomp_test_wine.png > > One of the main issues here is that the background turns black. This is because the foreground (swapchain) is not alpha-blended with the background (GDI); instead, it is simply overlaid using BitBlt. > > ``` > * BitBlt(dst_dc, 0, 0, rect.right - rect.left, rect.bottom - rect.top, src_dc, 0, 0, SRCCOPY); > * > ``` > > So I added an alpha_blend step here instead of simply using the original BitBlt. > > ``` > s1 = src_data; > d1 = dst_data; > for (int i = 0; i < height; i++) > { > for (int j = 0; j < width; j++) > { > // src is alpha pre multiple > float bg_alpha = ((255.f - s1[3])) / 255; > d1[0] = (d1[0] * bg_alpha) + s1[0]; > d1[1] = (d1[1] * bg_alpha) + s1[1]; > d1[2] = (d1[2] * bg_alpha) + s1[2]; > > s1 += 4; > d1 += 4; > } > } > > //iret = SetDIBits(dst_hdc, dst_bitmap, 0, height, dst_data, &bmi, DIB_RGB_COLORS); > iret = SetDIBitsToDevice(dst_hdc, 0, 0, width, height, > 0, 0, 0, height, dst_data, &bmi, DIB_RGB_COLORS); > ``` > The new display effect is as follows. > dcomp_test_wine_alpha_blend.png > It looks like basic blending is working, but the alpha values of the circles are lost. After analyzing the issue, I found the following cause. > > > I'll draw a diagram to briefly illustrate the cause of this issue. > > My original expectation of the image generation process > > flush1.png > > But the actual process is as follows > > image.png > > After the bitmap is alpha-blended and displayed on the screen, it is retrieved again in the next frame and repeatedly involved in alpha blending — resulting in redundant computations. > > > > I personally think that a more reasonable solution would be to insert |window_surface_composition| within |window_surface_flush| to more thoroughly resolve these kinds of issues > > image.png > > > During |window_surface_flush|, composite the current surface with the swapchain's surface into an offscreen surface, then flush that to the screen. This way, the original window surface won't be affected. Sounds reasonable. > > I'm trying to fix this issue now — do you have any suggestions? > > >

June 19, 2025

Does the timing of composition need to be moved from dcomp.dll to win32u?

by zhengxianwei

Zhiyi Zhang provided an implementation of DComp composition： https://gitlab.winehq.org/zhiyi/wine/-/commit/ef4f90c2ae909f4a732f0ebeae3b7… I created a simple sample that renders three equally sized red circles with varying alpha values on a plain white background window. On Windows, it displays as follows. [image: dcomp_test_window.png] But on Linux, it display as follows. [image: dcomp_test_wine.png] One of the main issues here is that the background turns black. This is because the foreground (swapchain) is not alpha-blended with the background (GDI); instead, it is simply overlaid using BitBlt. ``` * BitBlt(dst_dc, 0, 0, rect.right - rect.left, rect.bottom - rect.top, src_dc, 0, 0, SRCCOPY);* ``` So I added an alpha_blend step here instead of simply using the original BitBlt. ``` s1 = src_data; d1 = dst_data; for (int i = 0; i < height; i++) { for (int j = 0; j < width; j++) { // src is alpha pre multiple float bg_alpha = ((255.f - s1[3])) / 255; d1[0] = (d1[0] * bg_alpha) + s1[0]; d1[1] = (d1[1] * bg_alpha) + s1[1]; d1[2] = (d1[2] * bg_alpha) + s1[2]; s1 += 4; d1 += 4; } } //iret = SetDIBits(dst_hdc, dst_bitmap, 0, height, dst_data, &bmi, DIB_RGB_COLORS); iret = SetDIBitsToDevice(dst_hdc, 0, 0, width, height, 0, 0, 0, height, dst_data, &bmi, DIB_RGB_COLORS); ``` The new display effect is as follows. [image: dcomp_test_wine_alpha_blend.png] It looks like basic blending is working, but the alpha values of the circles are lost. After analyzing the issue, I found the following cause. I'll draw a diagram to briefly illustrate the cause of this issue. My original expectation of the image generation process [image: flush1.png] But the actual process is as follows [image: image.png] After the bitmap is alpha-blended and displayed on the screen, it is retrieved again in the next frame and repeatedly involved in alpha blending — resulting in redundant computations. I personally think that a more reasonable solution would be to insert window_surface_composition within window_surface_flush to more thoroughly resolve these kinds of issues [image: image.png] During window_surface_flush, composite the current surface with the swapchain's surface into an offscreen surface, then flush that to the screen. This way, the original window surface won't be affected. I'm trying to fix this issue now — do you have any suggestions?

June 19, 2025

Wine staging 10.10 release

by Alistair Leslie-Hughes

Binary packages for various distributions will be available from: https://www.winehq.org/download Summary since last release * Rebased to current wine 10.10 (348 patches are applied to wine vanilla) Upstreamed (Either directly from staging or fixed with a similar patch). * None. Removed (No longer required). * None Added: * None Updated: * vkd3d-latest Where can you help * Run Steam/Battle.net/GOG/UPlay/Epic * Test your favorite game. * Test your favorite applications. * Improve staging patches and get them accepted upstream. * Suggest patches to be included in staging. As always, if you find a bug, please report it via https://bugs.winehq.org Best Regards Alistair.

June 14, 2025

Re: Is it normal that the COM vtbl structure cannot be aligned between Windows and Wine

by zhengxianwei

Due to some reasons, I may not submit patches to Wine, but thank you for letting me know about this rule — I will follow it On Wed, Jun 11, 2025 at 8:57 PM Zhiyi Zhang <zzhang(a)codeweavers.com> wrote: > > > On 6/11/25 20:16, zhengxianwei wrote: > > In wine, Visual2Vtbl > > > > ``` > > typedef struct IDCompositionVisual2Vtbl { > > BEGIN_INTERFACE > > > > /*** IUnknown methods ***/ > > HRESULT (STDMETHODCALLTYPE *QueryInterface)( > > IDCompositionVisual2 *This, > > REFIID riid, > > void **ppvObject); > > > > ULONG (STDMETHODCALLTYPE *AddRef)( > > IDCompositionVisual2 *This); > > > > ULONG (STDMETHODCALLTYPE *Release)( > > IDCompositionVisual2 *This); > > > > /*** IDCompositionVisual methods ***/ > > HRESULT (STDMETHODCALLTYPE *SetOffsetX)( > > IDCompositionVisual2 *This, > > float offset_x); > > > > HRESULT (STDMETHODCALLTYPE *SetOffsetXAnimation)( > > IDCompositionVisual2 *This, > > IDCompositionAnimation *animation); > > > > HRESULT (STDMETHODCALLTYPE *SetOffsetY)( > > IDCompositionVisual2 *This, > > float offset_y); > > ``` > > > > setOffsetX (float *) at offset 0x18 > > visual2vtbl.png > > But in windows 0x18 is setOffsetX (Animation *) > > > > This screenshot is from disassembling native dcomp.dll. You are not > allowed to do this if you want to > send your patches to Wine. > > > > Is this correct? > > > > > > > > > >

June 11, 2025

Re: Is it normal that the COM vtbl structure cannot be aligned between Windows and Wine

by Zhiyi Zhang

On 6/11/25 20:16, zhengxianwei wrote: > In wine, Visual2Vtbl > > ``` > typedef struct IDCompositionVisual2Vtbl { > BEGIN_INTERFACE > > /*** IUnknown methods ***/ > HRESULT (STDMETHODCALLTYPE *QueryInterface)( > IDCompositionVisual2 *This, > REFIID riid, > void **ppvObject); > > ULONG (STDMETHODCALLTYPE *AddRef)( > IDCompositionVisual2 *This); > > ULONG (STDMETHODCALLTYPE *Release)( > IDCompositionVisual2 *This); > > /*** IDCompositionVisual methods ***/ > HRESULT (STDMETHODCALLTYPE *SetOffsetX)( > IDCompositionVisual2 *This, > float offset_x); > > HRESULT (STDMETHODCALLTYPE *SetOffsetXAnimation)( > IDCompositionVisual2 *This, > IDCompositionAnimation *animation); > > HRESULT (STDMETHODCALLTYPE *SetOffsetY)( > IDCompositionVisual2 *This, > float offset_y); > ``` > > setOffsetX (float *) at offset 0x18 > visual2vtbl.png > But in windows 0x18 is setOffsetX (Animation *) > This screenshot is from disassembling native dcomp.dll. You are not allowed to do this if you want to send your patches to Wine. > Is this correct? > > >

June 11, 2025

Re: Is it normal that the COM vtbl structure cannot be aligned between Windows and Wine

by zhengxianwei

cool job, thank you On Wed, Jun 11, 2025 at 8:51 PM Zhiyi Zhang <zzhang(a)codeweavers.com> wrote: > > > On 6/11/25 20:16, zhengxianwei wrote: > > In wine, Visual2Vtbl > > > > ``` > > typedef struct IDCompositionVisual2Vtbl { > > BEGIN_INTERFACE > > > > /*** IUnknown methods ***/ > > HRESULT (STDMETHODCALLTYPE *QueryInterface)( > > IDCompositionVisual2 *This, > > REFIID riid, > > void **ppvObject); > > > > ULONG (STDMETHODCALLTYPE *AddRef)( > > IDCompositionVisual2 *This); > > > > ULONG (STDMETHODCALLTYPE *Release)( > > IDCompositionVisual2 *This); > > > > /*** IDCompositionVisual methods ***/ > > HRESULT (STDMETHODCALLTYPE *SetOffsetX)( > > IDCompositionVisual2 *This, > > float offset_x); > > > > HRESULT (STDMETHODCALLTYPE *SetOffsetXAnimation)( > > IDCompositionVisual2 *This, > > IDCompositionAnimation *animation); > > > > HRESULT (STDMETHODCALLTYPE *SetOffsetY)( > > IDCompositionVisual2 *This, > > float offset_y); > > ``` > > > > setOffsetX (float *) at offset 0x18 > > visual2vtbl.png > > But in windows 0x18 is setOffsetX (Animation *) > > > > Is this correct? > > > > No. This is a bug. It's addressed by > https://gitlab.winehq.org/zhiyi/wine/-/commit/1ef17ccd021d7b549abeabdbcf9e1… > . > Please see > https://gitlab.winehq.org/zhiyi/wine/-/commits/bug-23698-react-native if > you want the latest dcomp work. > > > > >

June 11, 2025

Re: Is it normal that the COM vtbl structure cannot be aligned between Windows and Wine

by Zhiyi Zhang

On 6/11/25 20:16, zhengxianwei wrote: > In wine, Visual2Vtbl > > ``` > typedef struct IDCompositionVisual2Vtbl { > BEGIN_INTERFACE > > /*** IUnknown methods ***/ > HRESULT (STDMETHODCALLTYPE *QueryInterface)( > IDCompositionVisual2 *This, > REFIID riid, > void **ppvObject); > > ULONG (STDMETHODCALLTYPE *AddRef)( > IDCompositionVisual2 *This); > > ULONG (STDMETHODCALLTYPE *Release)( > IDCompositionVisual2 *This); > > /*** IDCompositionVisual methods ***/ > HRESULT (STDMETHODCALLTYPE *SetOffsetX)( > IDCompositionVisual2 *This, > float offset_x); > > HRESULT (STDMETHODCALLTYPE *SetOffsetXAnimation)( > IDCompositionVisual2 *This, > IDCompositionAnimation *animation); > > HRESULT (STDMETHODCALLTYPE *SetOffsetY)( > IDCompositionVisual2 *This, > float offset_y); > ``` > > setOffsetX (float *) at offset 0x18 > visual2vtbl.png > But in windows 0x18 is setOffsetX (Animation *) > > Is this correct? > No. This is a bug. It's addressed by https://gitlab.winehq.org/zhiyi/wine/-/commit/1ef17ccd021d7b549abeabdbcf9e1…. Please see https://gitlab.winehq.org/zhiyi/wine/-/commits/bug-23698-react-native if you want the latest dcomp work.

June 11, 2025

Is it normal that the COM vtbl structure cannot be aligned between Windows and Wine

by zhengxianwei

In wine, Visual2Vtbl ``` typedef struct IDCompositionVisual2Vtbl { BEGIN_INTERFACE /*** IUnknown methods ***/ HRESULT (STDMETHODCALLTYPE *QueryInterface)( IDCompositionVisual2 *This, REFIID riid, void **ppvObject); ULONG (STDMETHODCALLTYPE *AddRef)( IDCompositionVisual2 *This); ULONG (STDMETHODCALLTYPE *Release)( IDCompositionVisual2 *This); /*** IDCompositionVisual methods ***/ HRESULT (STDMETHODCALLTYPE *SetOffsetX)( IDCompositionVisual2 *This, float offset_x); HRESULT (STDMETHODCALLTYPE *SetOffsetXAnimation)( IDCompositionVisual2 *This, IDCompositionAnimation *animation); HRESULT (STDMETHODCALLTYPE *SetOffsetY)( IDCompositionVisual2 *This, float offset_y); ``` setOffsetX (float *) at offset 0x18 [image: visual2vtbl.png] But in windows 0x18 is setOffsetX (Animation *) Is this correct?

June 11, 2025

Re: Mismatch Between win32syscalls.h and Windows System Call Numbers

by Alexandre Julliard

Paul Gofman <pgofman(a)codeweavers.com> writes: >> DVDFab depends on the syscalls matching the Windows 10 numbering when >> running on Windows 10. I think that's a good reason why Wine's syscall >> numbers should be changed to match those of the default Windows >> version in winecfg. See >> https://bugs.winehq.org/show_bug.cgi?id=58043#c4 >> >> -Alex > Probably worth noting that the syscall numbers can't just be arbitrary > assigned to what Windows has on the current version. There are few > known cases when game detect those numbers not based on hardcoding per > Windows version and not based on parsing syscall thunk, but based on > the fact syscalls are sequentually ordered (starting from 0) on > Windows when sorted by Nt function address in ntdll. There is now a > test for that in commit ad6c662c468812549a636fcc0f66ec3f824c2675. So > the solution probably has to have the syscall functions set matching > Windows for the default Wine version in some way. I have some patches for this that will go in with today's commit round. -- Alexandre Julliard julliard(a)winehq.org

June 5, 2025

Re: Mismatch Between win32syscalls.h and Windows System Call Numbers

by Paul Gofman

> DVDFab depends on the syscalls matching the Windows 10 numbering when > running on Windows 10. I think that's a good reason why Wine's syscall > numbers should be changed to match those of the default Windows > version in winecfg. See > https://bugs.winehq.org/show_bug.cgi?id=58043#c4 > > -Alex Probably worth noting that the syscall numbers can't just be arbitrary assigned to what Windows has on the current version. There are few known cases when game detect those numbers not based on hardcoding per Windows version and not based on parsing syscall thunk, but based on the fact syscalls are sequentually ordered (starting from 0) on Windows when sorted by Nt function address in ntdll. There is now a test for that in commit ad6c662c468812549a636fcc0f66ec3f824c2675. So the solution probably has to have the syscall functions set matching Windows for the default Wine version in some way.

June 5, 2025