March 2024 - Wine-gitlab - list.winehq.org

Re: [PATCH v4 0/1] MR3422: ddraw tests for Pick and GetPickRecords
by Stefan Dösinger 04 Mar '24

04 Mar '24

My memory on this patchset is a bit rusty, but largely this looks good. I'll give it a try on my windows box tomorrow or Wednesday and report back. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3422#note_63423

1 0

Re: [PATCH v4 0/1] MR3422: ddraw tests for Pick and GetPickRecords
by Stefan Dösinger 04 Mar '24

04 Mar '24

Stefan Dösinger (@stefan) commented about dlls/ddraw/tests/ddraw1.c: > + pick_rect.y1 = pick_rect.y2 = 360; > + record_count = get_pickrecords(device, execute_buffer, viewport, &pick_rect, 3, &record[0]); > + if (record_count == 3) > + { > + /* Documentation states this list is z-ordered, but it appears that it is not. */ > + check_pickrecord(&record[0], D3DOP_TRIANGLE, quad_offset + 4, 0.25f); > + check_pickrecord(&record[1], D3DOP_TRIANGLE, quad_offset + 32, 0.75f); > + check_pickrecord(&record[2], D3DOP_TRIANGLE, quad_offset + 44, 0.5f); > + } > + > + /* Pick a pixel outside of viewport */ > + pick_rect.x1 = pick_rect.x2 = -8; > + pick_rect.y1 = pick_rect.y2 = -8; > + record_count = get_pickrecords(device, execute_buffer, viewport, &pick_rect, 1, &record[0]); > + if (record_count == 1) > + check_pickrecord(&record[0], D3DOP_TRIANGLE, quad_offset + 64, 0.2f); Interesting :-) -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3422#note_63422

1 0

Re: [PATCH v4 0/1] MR3422: ddraw tests for Pick and GetPickRecords
by Stefan Dösinger 04 Mar '24

04 Mar '24

Stefan Dösinger (@stefan) commented about dlls/ddraw/tests/ddraw1.c: > + > + /* Pick a pixel where multiple quads are present */ > + pick_rect.x1 = pick_rect.x2 = 64; > + pick_rect.y1 = pick_rect.y2 = 360; > + record_count = get_pickrecords(device, execute_buffer, viewport, &pick_rect, 3, &record[0]); > + if (record_count == 3) > + { > + /* Documentation states this list is z-ordered, but it appears that it is not. */ > + check_pickrecord(&record[0], D3DOP_TRIANGLE, quad_offset + 12, -0.5f); > + check_pickrecord(&record[1], D3DOP_TRIANGLE, quad_offset + 32, 6.5f); > + check_pickrecord(&record[2], D3DOP_TRIANGLE, quad_offset + 52, -3.0f); > + > + /* If the count is wrong, do not populate any records */ > + memset(&record, 0, sizeof(record)); > + record_count = 1; > + hr = IDirect3DDevice_GetPickRecords(device, &record_count, &record[0]); I would expect it to write 3 pick records if the input size in record_count is larger than the number retrieved. I.e., if you set record_count = 4 and make the array large enough it should write 3 and leave the 4th untouched. That's the usual pattern for getters like this at least. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3422#note_63420

1 0

Re: [PATCH v4 0/1] MR3422: ddraw tests for Pick and GetPickRecords
by Stefan Dösinger 04 Mar '24

04 Mar '24

Stefan Dösinger (@stefan) commented about dlls/ddraw/tests/ddraw1.c: > + /* Pick a pixel where no quads are present */ > + pick_rect.x1 = pick_rect.x2 = 480; > + pick_rect.y1 = pick_rect.y2 = 360; > + get_pickrecords(device, execute_buffer, viewport, &pick_rect, 0, NULL); > + > + /* Pick a pixel where one quad is present */ > + pick_rect.x1 = pick_rect.x2 = 120; > + pick_rect.y1 = pick_rect.y2 = 120; > + record_count = get_pickrecords(device, execute_buffer, viewport, &pick_rect, 1, &record[0]); > + if (record_count == 1) > + check_pickrecord(&record[0], D3DOP_TRIANGLE, quad_offset + 12, 0.25f); > + > + /* Pick a pixel where quad is clipped */ > + pick_rect.x1 = pick_rect.x2 = 40; > + pick_rect.y1 = pick_rect.y2 = 120; > + get_pickrecords(device, execute_buffer, viewport, &pick_rect, 0, NULL); What does clipped mean here? Outside of the 0.0;1.0 depth range? In the TLVERTEX case you get depth values -0.5, 6.5 and -3.0, suggesting that the near and far clip planes don't matter. If I understand this test here right they do matter for LVERTEX. That is consistent with later d3d versions where Z clipping is essentially disabled when drawing pretransformed geometry with the right settings. Another way to look at this is that Z clipping is done by D3DPROCESSVERTICES_TRANSFORM not the draw op (D3DOP_TRIANGLE). -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3422#note_63421

1 0

Re: [PATCH v2 0/1] MR685: vkd3d-shader/hlsl: Write the SFI0 section and "REQUIRES_ROVS" flag when ROVs are used.
by Zebediah Figura (＠zfigura) 04 Mar '24

04 Mar '24

Yes, both of those were my thought process as well. -- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/685#note_63419

1 0

[PATCH 0/6] MR5224: Explicitly request debug info in critical sections.
by Paul Gofman (＠gofman) 04 Mar '24

04 Mar '24

See https://gitlab.winehq.org/wine/wine/-/merge_requests/5071 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5224

5 9

[PATCH 0/4] MR5216: msi: Fix costing calculations a bit, and avoid overflow.
by Zebediah Figura (＠zfigura) 04 Mar '24

04 Mar '24

This work is based on Wine-Staging patch "msi-msi_vcl_get_cost" by Mark Jansen. That patch attempts to avoid overflow, although not particularly well, since the damage would already have been done by calculate_file_cost(). This patch series addresses the issue in both places. The Wine-Staging patch seems to have originally been written in an attempt to address a bug visible with (at least) some Microsoft Office and LibreOffice installers where file costs would render incorrectly. That bug is recorded as ReactOS bug 12229 [1], which report includes both the patch to vcl_get_cost(), and the patch fixing the actual bug, which did eventually made it upstream as b53957df2a73ae51ca6ebc1e88bb9c4ed8b8d274. [1] https://jira.reactos.org/browse/CORE-12229 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5216

4 9

[PATCH v2 0/7] MR5215: shell32: shell32: Implement Paste in the item menu.
by Zebediah Figura (＠zfigura) 04 Mar '24

04 Mar '24

-- v2: shell32: Implement Paste in the item menu. shell32: Respect the parent PIDL when pasting from CFSTR_SHELLIDLIST. shell32: Reimplement pasting from CF_DROP directly. shell32: Add a get_data_format() helper. shell32: Move DoPaste() up. shell32: Remove useless and commented out code. shell32/tests: Add tests for context menu copy/paste. https://gitlab.winehq.org/wine/wine/-/merge_requests/5215

2 8

[PATCH v2 0/1] MR5188: Draft: winemac.drv: Hide app's dock icon when it wouldn't have a taskbar item on Windows.
by Tim Clem (＠tclem) 04 Mar '24

04 Mar '24

This is a change from the default behavior in macdrv for as long as it's existed, as far as I can tell. Previously, gaining a dock icon was a one-way path. However, that doesn't jive with the way taskbar entries work on Windows; if an app has no windows, it doesn't appear in the taskbar. This patch attempts to remedy cases where an app winds up with superfluous dock icons for exe's that no longer have windows (looking at you, basically every launcher and Steam). The major concern I can see with this is that if an app closes all of its windows but does not exit, there will be no indication that it is still running. Two thoughts on that: 1. That *should* be an anomalous case, such as the app hanging on exit. 2. Effectively the same behavior would happen on Windows. I would love to hear any other thoughts about this change. I'm open (though I would not prefer it) to defaulting the registry key to false if that would alleviate any concerns. -- v2: winemac.drv: Hide app's dock icon when it wouldn't have a taskbar item on Windows. https://gitlab.winehq.org/wine/wine/-/merge_requests/5188

2 3

[PATCH 0/2] MR688: tests/shader_runner: Set the SPIR-V feature flags based on the runner caps.
by Henri Verbeet (＠hverbeet) 04 Mar '24

04 Mar '24

-- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/688

3 4