- wine-gitlab - winehq.org

Re: [PATCH v3 0/8] MR2801: winemac: Use a new type of NtUserMessageCall to move IME input processing to imm32. - approved
by Alexandre Julliard (＠julliard) 12 May '23

12 May '23

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2801

1 0

Re: [PATCH v4 0/1] MR2795: d3dx9_36: Stub D3DXComputeTangent
by Zebediah Figura (＠zfigura) 12 May '23

12 May '23

On Fri May 12 21:07:04 2023 +0000, Matteo Bruni wrote: > Ah, now I realize I read the "go further" in the MR description as > "work". I'd like to know that too. I kind of ask because—while I don't want to hold up progress upstream—as the person who is both maintaining the Wine-Staging patch, and working on (admittedly long stalled) actual tests for tangents, if this doesn't actually help the bug, all this patch is going to do is add more rebase headache for me. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2795#note_32671

1 0

Re: [PATCH v4 0/1] MR2795: d3dx9_36: Stub D3DXComputeTangent
by Matteo Bruni (＠Mystral) 12 May '23

12 May '23

On Fri May 12 21:07:04 2023 +0000, Zebediah Figura wrote: > Does this actually make the program work? Ah, now I realize I read the "go further" in the MR description as "work". I'd like to know that too. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2795#note_32670

1 0

Re: [PATCH v4 0/1] MR2795: d3dx9_36: Stub D3DXComputeTangent
by Zebediah Figura (＠zfigura) 12 May '23

12 May '23

Does this actually make the program work? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2795#note_32669

1 0

Re: [PATCH v4 0/1] MR2795: d3dx9_36: Stub D3DXComputeTangent
by Matteo Bruni (＠Mystral) 12 May '23

12 May '23

Matteo Bruni (@Mystral) commented about dlls/d3dx9_36/mesh.c: > return hr; > } > > +/************************************************************************* > + * D3DXComputeTangent (D3DX9_36.@) > + */ > +HRESULT WINAPI D3DXComputeTangent(ID3DXMesh *mesh, const DWORD stage_idx, DWORD tangent_idx, That "const" shouldn't be there. I guess it doesn't matter in practice but it does look quite weird. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2795#note_32666

1 0

Re: [PATCH v4 0/1] MR2795: d3dx9_36: Stub D3DXComputeTangent
by Matteo Bruni (＠Mystral) 12 May '23

12 May '23

Matteo Bruni (@Mystral) commented about dlls/d3dx9_36/mesh.c: > return hr; > } > > +/************************************************************************* > + * D3DXComputeTangent (D3DX9_36.@) > + */ > +HRESULT WINAPI D3DXComputeTangent(ID3DXMesh *mesh, const DWORD stage_idx, DWORD tangent_idx, > + DWORD binorm_idx, DWORD wrap, const DWORD *adjacency) > +{ > + FIXME("mesh %p, stage_idx %lu, tangent_idx %lu, binorm_idx %lu, wrap %lu, adjacency %p.\n", We usually end FIXME messages for stubs with "stub!\n". -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2795#note_32667

1 0

Re: [PATCH v4 0/1] MR2795: d3dx9_36: Stub D3DXComputeTangent
by Matteo Bruni (＠Mystral) 12 May '23

12 May '23

Matteo Bruni (@Mystral) commented about dlls/d3dx9_36/mesh.c: > return hr; > } > > +/************************************************************************* > + * D3DXComputeTangent (D3DX9_36.@) > + */ Your choice, but I would just get rid of this comment header. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2795#note_32668

1 0

[PATCH 0/5] MR2805: winemac: High-res/retina mode fixes
by Brendan Shanks (＠bshanks) 12 May '23

12 May '23

This fixes two issues: - since WineContentView became layer-backed in Wine 6.17, windows do not display correctly on a non-retina monitor when high-res/retina mode is enabled. (The needed downscaling was not being done). - additionally on macOS 10.13 and earlier, the desired minification/downscaling filter was being ignored, causing poor image quality. Enabling rasterization for the layer seems to work around this and uses the correct filter. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2805

2 5

[PATCH v2 0/4] MR2800: ntdll/heap: Reduce memory footprint by better matching Windows subheap sizes
by Paul Gofman (＠gofman) 12 May '23

12 May '23

Turns out Windows is more conservative both in initial allocation when creating new heap and also in growing the heap. Comments: - Without patch 1 the related test in test_block_layout fails on x64 for me ("unexpected padding") after the last patch. I don't think the last patches really changes much in this regard, looks like the test just depends on the uninitialized data; - Without patch 2 test_HeapCreate fails (line 601 where it checks the last block pointer). I think it is also only triggered by my patch, I think that last block detection only works correctly now when commit size is smaller than the subheap size (which happens to be not the case in the test after the last patch); - The last patch extends a bit a todo in test_block_layout(). The actual reason for (extended) todo is that we are probably not handling pending free blocks quite like on Windows. I watched the pointers on Windows in the same test and they are always withing the same subheap allocation which suggests that Windows might be reusing pending free block once it can't find normal free block and before extending the heap. So the last patch changes subheap sizes and that triggers different subheaps for the allocated pointers in Wine. So it looks like not an actual issue with my patch. Reusing pending free pointers is apparently possible to implement but it seems to me that it doesn't worth the trouble until anything depends on that (since those pending free blocks are only there when heap debug flags are enabled which is rarely the case outside of debugging). -- v2: ntdll: Better match Windows subheap sizes. kernel32/tests: Add tests for subheap sizes. ntdll: Fix last block detection in heap_walk_blocks(). ntdll: Fix tail padding in mark_block_tail(). https://gitlab.winehq.org/wine/wine/-/merge_requests/2800

2 5

[PATCH 0/4] MR2800: ntdll/heap: Reduce memory footprint by better matching Windows subheap sizes
by Paul Gofman (＠gofman) 12 May '23

12 May '23

Turns out Windows is more conservative both in initial allocation when creating new heap and also in growing the heap. Comments: - Without patch 1 the related test in test_block_layout fails on x64 for me ("unexpected padding") after the last patch. I don't think the last patches really changes much in this regard, looks like the test just depends on the uninitialized data; - Without patch 2 test_HeapCreate fails (line 601 where it checks the last block pointer). I think it is also only triggered by my patch, I think that last block detection only works correctly now when commit size is smaller than the subheap size (which happens to be not the case in the test after the last patch); - The last patch extends a bit a todo in test_block_layout(). The actual reason for (extended) todo is that we are probably not handling pending free blocks quite like on Windows. I watched the pointers on Windows in the same test and they are always withing the same subheap allocation which suggests that Windows might be reusing pending free block once it can't find normal free block and before extending the heap. So the last patch changes subheap sizes and that triggers different subheaps for the allocated pointers in Wine. So it looks like not an actual issue with my patch. Reusing pending free pointers is apparently possible to implement but it seems to me that it doesn't worth the trouble until anything depends on that (since those pending free blocks are only there when heap debug flags are enabled which is rarely the case outside of debugging). -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2800

3 10

2025

2024

2023

2022

wine-gitlab