July 2023 - Wine-GitLab - list.winehq.org

Re: [PATCH v3 0/6] MR3165: dxgi: Introduce a worker thread for each D3D12 swapchain (first part).
by Zhiyi Zhang (＠zhiyi) July 4, 2023

July 4, 2023

On Mon Jul 3 18:50:55 2023 +0000, Zebediah Figura wrote: > > With this implementation it should be relatively easy to present with > whatever API is available, though I don't really know how the options > you mention work, so maybe there is some additional complexity I'm not > aware of. > Sounds great :-) > The "fullscreen window styles" problem (and one of the older d3d > contributors can correct me on this) is basically that some applications > use ddraw (and other versions?) to present to a fullscreen window, > expecting the presented area to cover the whole screen, but wgl (and > Vulkan) swapchains only present to the client rect. We currently get > around this by changing the window styles to remove all the nonclient > decorations, but that breaks some applications too. What we want is a > way to present to the actual window, and part of the idea is that using > D3DKMTPresent() is the architecturally correct way to do this. > I don't quite know what the concerns are for dcomposition either. Zhiyi > was looking at that and ran into a wall, but he probably can at least > describe the problem in greater detail. > There are also some thoughts about using D3DKMTPresent() to deal more > efficiently with some cases where we currently have to do a GDI blit. > I'm fuzzy on these details though; again Henri can explain it better. What D3DKMTPresent() does is that it sends a command to the compositor/DWM to display contents. Since DWM is responsible for drawing the window decoration, it allows the nonclient decorations to be overwritten without affecting window styles. The complexity here is that we don't have a DWM. Implementing a DWM and making it work with the host WM is not trivial, if not impossible. Also, the window decoration is currently handled by the host system, for example, Mutter. Having D3DKMTPresent() is certainly more architecturally correct. That way, DWM can intercept these surfaces and do the composition without tearing and not worry about the surface lifetime. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3165#note_37742

1 0

[PATCH 0/71] MR3168: Draft: Release 8.0.2.
by Michael Stefaniuc (＠mstefani) July 4, 2023

July 4, 2023

-- 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/3168

3 3

Re: [PATCH v10 0/2] MR3074: Move getpeername() implementation to wineserver
by Chip Davis (＠cdavis5e) July 4, 2023

July 4, 2023

Typically, `todo_wine` is removed in the commit that fixes the behavior of the underlying API function. (This may be the reason your change hasn't been merged yet.) -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3074#note_37738

1 0

[PATCH 0/2] MR3232: d3d10core/tests: Mark test failures specific to the Vulkan or GL renderers.
by Zebediah Figura (＠zfigura) July 4, 2023

July 4, 2023

This is obviously questionable, as it requires reaching into Wine internals in tests (beyond simply detecting whether Wine is in use). However, we are at a point where, for d3d10 and above, the Vulkan renderer works well enough in general to see real use [in fact, in my experience it usually works better than the GL renderer], and at this point I think avoiding regressions is quite important. It is currently difficult to run tests with it when the results contain so much noise, and I think we need to solve this problem, by actually marking which tests work on each backend. We could in theory expose the renderer through some adapter string, but I believe in the past applications have been sensitive about the contents of adapter strings. Fixing either renderer to reach and maintain parity is not feasible. The GL renderer is not going away, but regrettably GL as an API is abandoned by Khronos, and important features we need in order to implement some Direct3D features will probably never be introduced into GL. Moreover, the amount of effort that would be required to reach parity is not small, and itself would all need to be verified manually. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3232

3 3

[PATCH 0/6] MR259: vkd3d-shader/dxil: Read the DXIL module.
by Conor McCarthy (＠cmccarthy) July 4, 2023

July 4, 2023

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

3 24

Re: [PATCH v3 0/6] MR3165: dxgi: Introduce a worker thread for each D3D12 swapchain (first part). - approved
by Zebediah Figura (＠zfigura) July 3, 2023

July 3, 2023

This merge request was approved by Zebediah Figura. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3165

1 0

Re: [PATCH v3 0/1] MR3227: winedump: Add support for dumping IMPORT_OBJECT_NAME_EXPORTAS symbols. - approved
by Alexandre Julliard (＠julliard) July 3, 2023

July 3, 2023

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

1 0

Re: [PATCH v2 0/1] MR3229: mshtml: Remove DECLSPEC_HIDDEN usage. - approved
by Alexandre Julliard (＠julliard) July 3, 2023

July 3, 2023

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

1 0

Re: [PATCH v3 0/2] MR3207: Remove DECLSPEC_HIDDEN from scripting DLL (VBSCript/JScript) - approved
by Alexandre Julliard (＠julliard) July 3, 2023

July 3, 2023

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

1 0

Re: [PATCH v6 0/2] MR3186: ntdll/unix: Skip address conversion for TCP sockets in try_send(). - approved
by Alexandre Julliard (＠julliard) July 3, 2023

July 3, 2023

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

1 0