February 2024 - Wine-gitlab

[PATCH v6 0/3] MR3876: Zero-width character handling in GetTextExtentExPoint[AWI]
by Torge Matthies (＠tmatthies) 19 Feb '24

19 Feb '24

Certain characters are considered by GetTextExtentExPointA/W/I to have no width, even if they have a non-zero width and a shape in the font. This MR attempts to bring Wine's implementation of these functions closer to native behavior. One remaining difference is caused by GetGlyphIndicesA/W returning 0 instead of 0xffff for some characters, for some reason. This also affects the handling by GetTextExtentExPointA/W/I of affected characters. I have compared this with both Uniscribe and DWrite behavior and neither of them match this behavior, so it seems to be a peculiarity of these older functions. Remaining differences are probably caused by differences in the fallback fonts used when a character is missing from the selected font. Notably, on my system there doesn't seem to be a fallback font for `\t`/`\n`/`\r` that marks those characters as zero-width, and since applications are likely to depend on the metrics of those characters (I know of at least one), I have opted to explicitly make them zero-width in this MR, even though that is technically not what Windows does. -- v6: win32u: Handle glyphs that are marked by the font as zero-width in GetTextExtentExPoint[AWI]. win32u: Use maximum of (A, A+C, A+C+B) width for character fit test in GetTextExtentExPoint[AWI]. gdi32/tests: Add test for width of carriage return and line feed. https://gitlab.winehq.org/wine/wine/-/merge_requests/3876

3 4

Re: [PATCH v12 0/5] MR3572: mf: Make session_get_node_object() more robust.
by Zhiyi Zhang (＠zhiyi) 19 Feb '24

19 Feb '24

On Mon Feb 19 09:21:14 2024 +0000, Rémi Bernon wrote: > Fwiw this, and more specifically the test in > 6b853a9354dfe62df838b255b4af33b423e74642, triggers an assertion in > threadpool. It somehow doesn't make the test report a failure but I > think it can cause some spurious failures like in > https://gitlab.winehq.org/rbernon/wine/-/jobs/56730#L1220 which doesn't > seem related to the H264 decoder changes from the corresponding MR. I will take a look. Thanks. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3572#note_61850

1 0

Re: [PATCH v12 0/5] MR3572: mf: Make session_get_node_object() more robust.
by Rémi Bernon 19 Feb '24

19 Feb '24

Fwiw this, and more specifically the test in 6b853a9354dfe62df838b255b4af33b423e74642, triggers an assertion in threadpool. It somehow doesn't make the test report a failure but I think it can cause some spurious failures like in https://gitlab.winehq.org/rbernon/wine/-/jobs/56730#L1220 which doesn't seem related to the H264 decoder changes from the corresponding MR. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3572#note_61846

1 0

Re: [PATCH v2 0/2] MR5080: oleaut32: Use scientific notation only for larger numbers in VarBstrFromR[48].
by Rémi Bernon 19 Feb '24

19 Feb '24

Fwiw, this broke the tests on Linux (the pipeline was already failing here). -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5080#note_61845

1 0

[PATCH 0/1] MR5109: include: Annotate NdrGetBuffer with __WINE_(ALLOC_SIZE|MALLOC).
by Alex Henrie (＠alexhenrie) 19 Feb '24

19 Feb '24

It would be nice to annotate it with __WINE_DEALLOC(NdrFreeBuffer) too, but that causes a bunch of spurious -Wfree-nonheap-object warnings. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5109

2 1

[PATCH 0/5] MR5108: win32u: Don't assume that the primary adapter is always first.
by Rémi Bernon 19 Feb '24

19 Feb '24

In preparation for some virtual desktop refactor for display mode emulation (https://gitlab.winehq.org/wine/wine/-/merge_requests/5057) -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5108

1 5

[PATCH v14 0/191] MR648: Draft: vkd3d-shader: [Test] SM 6.
by Conor McCarthy (＠cmccarthy) 19 Feb '24

19 Feb '24

-- v14: vkd3d-shader/dxil: Bitcast the result of image atomic ops if necessary. vkd3d-shader/dxil: Emit an error for mesh, amplification and library shaders. vkd3d-shader/dxil: Support SV_ShadingRate. vkd3d-shader/dxil: Support the barycentrics register type. 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/vkd3d/-/merge_requests/648

1 0

[PATCH v13 0/187] MR648: Draft: vkd3d-shader: [Test] SM 6.
by Conor McCarthy (＠cmccarthy) 19 Feb '24

19 Feb '24

-- v13: vkd3d-shader/spirv: Support 64-bit UAV atomics. vkd3d-shader/dxil: Implement DX intrinsic WaveQuadReadLaneAt. vkd3d-shader/dxil: Implement DX intrinsic WavePrefixOp. 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/vkd3d/-/merge_requests/648

1 0

[PATCH v12 0/184] MR648: Draft: vkd3d-shader: [Test] SM 6.
by Conor McCarthy (＠cmccarthy) 19 Feb '24

19 Feb '24

-- v12: vkd3d-shader/dxil: Ignore "llvm.lifetime.*" intrinsics. vkd3d-shader/dxil: Implement DX intrinsic AnnotateHandle. vkd3d-shader/dxil: Implement DX intrinsic CreateHandleFromBinding. 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/vkd3d/-/merge_requests/648

1 0

[PATCH v7 0/1] MR3096: ntdll: Add NtGetNextProcess stub.
by Alex Henrie (＠alexhenrie) 18 Feb '24

18 Feb '24

The stub is enough for TokenViewer.exe to start up and display its user interface. Based on a patch by Nikolay Sivov. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=45119 -- v7: ntdll: Add NtGetNextProcess stub. https://gitlab.winehq.org/wine/wine/-/merge_requests/3096

2 1