This is similar to https://gitlab.winehq.org/wine/wine/-/merge_requests/2684, https://gitlab.winehq.org/wine/wine/-/merge_requests/3004 or https://gitlab.winehq.org/wine/wine/-/merge_requests/3139 but it validates the session transform node behavior with tests.
The tests are added after the changes because they otherwise don't pass and making them pass would be unnecessarily complicated.
I also have some local tests for MF_TOPONODE_WORKQUEUE_ID attributes and how it is supposed to behave. It basically creates new serialized work queues for every source node and assign them to every node downstream. Any sample request or processing operation is done in the associated queue.
When joining streams, queues are assigned downstream one after another and the last assigned queue is used when requesting samples upstream, but when samples are received and processed downstream it looks like the current queue of the source node is used for every downstream operations.
The request behavior seems to be the same when work queues are used, with round robin input requests, and single ProcessInput call followed by ProcessOutput loop until it fails.
This is yet not optimally efficient, and could be improved, for the following reasons:
1) All session operations are serialized together, even unrelated streams, and ProcessInput / ProcessOutput calls may be costly and stalling the pipeline. I believe that native probably allows parallel processing of unrelated stream requests, this needs to be confirmed.
2) MFT_MESSAGE_COMMAND_DRAIN message use isn't ideal, the message forces the transform to process all queued input synchronously, which can take a long time. I haven't checked exactly what native does but I believe it instead uses MFT_MESSAGE_NOTIFY_END_OF_STREAM messages, which would allow us to notify and drain the GStreamer decoder asynchronously.
3) MFT_MESSAGE_COMMAND_DRAIN also doesn't distinguish between input streams and needs to be sent globally. It's unclear how it should be used when multiple input streams are involved, and when one stream ends its segment then start a new segment while other streams don't have yet reached EOS. MFT_MESSAGE_NOTIFY_END_OF_STREAM messages have a stream ID parameter and would be more appropriate to handle separate input streams independently.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3245
When we are clipping (due to fullscreen), certain operations are bugged (such as creating another window on top, grabbing the window during a size-move operation, changing mouse capture, etc) so we must temporarily unclip first.
Seems unclipping it temporarily during such operation is enough to fix this.
This probably wasn't very obvious in practice because most times "fullscreen" means a single non-resizeable window with no menus and so on (e.g. fullscreen games), but that's not always the case.
--
v5: win32u: Don't clip fullscreen windows while capturing mouse pointer.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1153
When we are clipping (due to fullscreen), certain operations are bugged (such as creating another window on top, grabbing the window during a size-move operation, changing mouse capture, etc) so we must temporarily unclip first.
Seems unclipping it temporarily during such operation is enough to fix this.
This probably wasn't very obvious in practice because most times "fullscreen" means a single non-resizeable window with no menus and so on (e.g. fullscreen games), but that's not always the case.
--
v4: win32u: Don't clip fullscreen windows while capturing mouse pointer.
winex11: Don't clip while creating X Window.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1153
`getpeername()` is currently handled in ntdll. This merge request changes ntdll to forward `getpeername()` to wineserver. The implementation utilises new `peer_addr` and `peer_addr_len` fields in wineserver's `struct sock`.
This fixes multiple `todo_wine`s in `ws2_32/tests` and allows for more accurate peer names to be provided in case the address the socket is bound to on the Unix side does not match what `bind()` was called with on the Windows side.
*This merge request was originally intended to be included in !2786 (Add support for AF_UNIX sockets) but was split into its own merge request because this is not an insignificant change.*
--
v14: server: Move getpeername() implementation from ntdll/unix.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3074
Windows 10 [received support](https://devblogs.microsoft.com/commandline/af_unix-comes-to-window… for AF_UNIX sockets in Insider Build 17063. This merge request adds basic support for AF_UNIX sockets to ws2_32 and wineserver.
Of particular note is the difficulty in handling `sun_path`. Most of the functions that allow for translating Windows paths to Unix paths are not accessible from ws2_32. I considered the following options:
* Pass the Windows path to wineserver and do the conversion there.
* This is, as far as I can tell, not possible without major rearchitecting. wineserver does not have functions to translate Windows paths to Unix paths, for obvious reasons.
* Obtain the current working directory of the requesting process and temporarily change directories to there.
* This only handles relative paths and fails for absolute paths, UNC paths, etc.
* Conditionally change directories based on whether the path is relative or not.
* This is error-prone and wineserver does not have the requisite functions to do this cleanly.
I ultimately decided to pass the translated Unix path to wineserver, which changes directories to `dirname(path)`. It then provides `bind` and `connect` with `basename(path)`. This is not threadsafe, but wineserver is not (currently) multithreaded.
Abstract sockets are supported by this patch.
--
v35: ws2_32/tests: Add test for AF_UNIX sockets fix.
server: Fix getsockname() and accept() on AF_UNIX sockets.
server: Introduce error when attempting to connect() to abstract AF_UNIX sockets.
server: Allow for deletion of socket files.
ws2_32: Add support for AF_UNIX sockets.
ntdll/unix: Add support for AF_UNIX sockets to multiple functions.
ws2_32: Add afunix.h header.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2786
Signed-off-by: Bernhard Kölbl <besentv(a)gmail.com>
--
v7: include: Add VoiceCommandSet runtimeclass with it's dependencies.
include: Add Windows.Phone.PhoneContract api contract.
widl: Add basic support for the [deprecated] attribute.
https://gitlab.winehq.org/wine/wine/-/merge_requests/383
Signed-off-by: Bernhard Kölbl <besentv(a)gmail.com>
--
v5: include: Add VoiceCommandSet runtimeclass with it's dependencies.
include: Add Windows.Phone.PhoneContract api contract.
widl: Add basic support for the [deprecated] attribute.
https://gitlab.winehq.org/wine/wine/-/merge_requests/383
Signed-off-by: Bernhard Kölbl <besentv(a)gmail.com>
--
v4: include: Add VoiceCommandSet runtimeclass with it's dependencies.
include: Add Windows.Phone.PhoneContract api contract.
widl: Add basic support for the [deprecated] attribute.
https://gitlab.winehq.org/wine/wine/-/merge_requests/383
This is the first part of a series implementing an asynchronous MFT wrapper around the synchronous session transforms. The idea is to use the async MFT behavior for all the session transforms.
I believe this is generally useful, and goes in the direction of support native async MFT, although there is none at the moment, and it will also improve the behavior of the session with decoder transforms. These MFT do not generate a sample for each input samples, and may require more input to be requested. Using the async MFT behavior, we would generate METransformInputNeeded events when appropriate, and the session would react to them and request more samples from upstream.
Similarly, producing output will trigger METransformOutputAvailable events, and the session can react to these events and push the samples downstream if there were requested, or queue them.
Moreover, for very large video decoding or video processing, the synchronous transform may be performing slowly, and this currently blocks the session callbacks, causing stutter in the playback. Using the async MFT, we can process samples asynchronously, in the multi threaded queue.
The complete async_transform implementation can be seen in the https://gitlab.winehq.org/rbernon/wine/-/commits/mr/mf-async-transform branch. I also have a local tree with fully working decoder MFTs, but it requires more changes elsewhere and some media source refactor.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3139
Signed-off-by: Bernhard Kölbl <besentv(a)gmail.com>
--
v3: include: Add VoiceCommandSet runtimeclass with it's dependencies.
include: Add Windows.Phone.PhoneContract api contract.
fixup! widl: Add basic support for the [deprecated] attribute.
fixup! winedump: Add support for dumping IMPORT_OBJECT_NAME_EXPORTAS symbols.
widl: Add basic support for the [deprecated] attribute.
https://gitlab.winehq.org/wine/wine/-/merge_requests/383
--
v3: vkd3d-shader/hlsl: Free the "iter" block pointer on success in create_loop().
vkd3d-shader/hlsl: Return a hlsl_block from the "expr_statement" and "expr" rules.
vkd3d-shader/hlsl: Return a hlsl_block from the "jump_statement" rule.
vkd3d-shader/hlsl: Return a hlsl_block from the "selection_statement" rule.
vkd3d-shader/hlsl: Return a hlsl_block from the "loop_statement" rule.
vkd3d-shader/hlsl: Return a hlsl_block from the "statement" rule.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/258
On Wed Jul 6 09:01:08 2022 +0000, Rémi Bernon wrote:
> If we don't have anything to define it to, maybe it's not really worth
> generating anything to the header yet and only keep the parsing support?
I did it like this because idk if we support `__declspec(deprecated(x))` .
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/383#note_37972
And synchronize with thread display when necessary.
The rationale is that client_window are created using the gdi_display,
and OpenGL/Vulkan using gdi_display it is probably safer that any X11
request for them is done on the gdi_display.
Then we need to properly synchronize the requests that involve client_window
and whole_window, such as reparenting requests, as whole_window is created,
and related requests make, using the thread display.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3241
`getpeername()` is currently handled in ntdll. This merge request changes ntdll to forward `getpeername()` to wineserver. The implementation utilises new `peer_addr` and `peer_addr_len` fields in wineserver's `struct sock`.
This fixes multiple `todo_wine`s in `ws2_32/tests` and allows for more accurate peer names to be provided in case the address the socket is bound to on the Unix side does not match what `bind()` was called with on the Windows side.
*This merge request was originally intended to be included in !2786 (Add support for AF_UNIX sockets) but was split into its own merge request because this is not an insignificant change.*
--
v13: server: Move getpeername() implementation from ntdll/unix.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3074
`getpeername()` is currently handled in ntdll. This merge request changes ntdll to forward `getpeername()` to wineserver. The implementation utilises new `peer_addr` and `peer_addr_len` fields in wineserver's `struct sock`.
This fixes multiple `todo_wine`s in `ws2_32/tests` and allows for more accurate peer names to be provided in case the address the socket is bound to on the Unix side does not match what `bind()` was called with on the Windows side.
*This merge request was originally intended to be included in !2786 (Add support for AF_UNIX sockets) but was split into its own merge request because this is not an insignificant change.*
--
v12: server: Move getpeername() implementation from ntdll/unix.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3074
Windows 10 [received support](https://devblogs.microsoft.com/commandline/af_unix-comes-to-window… for AF_UNIX sockets in Insider Build 17063. This merge request adds basic support for AF_UNIX sockets to ws2_32 and wineserver.
Of particular note is the difficulty in handling `sun_path`. Most of the functions that allow for translating Windows paths to Unix paths are not accessible from ws2_32. I considered the following options:
* Pass the Windows path to wineserver and do the conversion there.
* This is, as far as I can tell, not possible without major rearchitecting. wineserver does not have functions to translate Windows paths to Unix paths, for obvious reasons.
* Obtain the current working directory of the requesting process and temporarily change directories to there.
* This only handles relative paths and fails for absolute paths, UNC paths, etc.
* Conditionally change directories based on whether the path is relative or not.
* This is error-prone and wineserver does not have the requisite functions to do this cleanly.
I ultimately decided to pass the translated Unix path to wineserver, which changes directories to `dirname(path)`. It then provides `bind` and `connect` with `basename(path)`. This is not threadsafe, but wineserver is not (currently) multithreaded.
Abstract sockets are supported by this patch.
--
v34: ws2_32/tests: Add test for AF_UNIX sockets fix.
server: Fix getsockname() and accept() on AF_UNIX sockets.
server: Introduce error when attempting to connect() to abstract AF_UNIX sockets.
server: Allow for deletion of socket files.
ws2_32: Add support for AF_UNIX sockets.
ntdll/unix: Add support for AF_UNIX sockets to multiple functions.
ws2_32: Add afunix.h header.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2786
`getpeername()` is currently handled in ntdll. This merge request changes ntdll to forward `getpeername()` to wineserver. The implementation utilises new `peer_addr` and `peer_addr_len` fields in wineserver's `struct sock`.
This fixes multiple `todo_wine`s in `ws2_32/tests` and allows for more accurate peer names to be provided in case the address the socket is bound to on the Unix side does not match what `bind()` was called with on the Windows side.
*This merge request was originally intended to be included in !2786 (Add support for AF_UNIX sockets) but was split into its own merge request because this is not an insignificant change.*
--
v11: server: Move getpeername() implementation from ntdll/unix.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3074
There are a few motivations for this:
* Identifiers beginning with vkd3d_shader_ look like external API. Changing the
prefix makes it clear that this is an internal API.
* vkd3d_shader is a very long prefix, which is annoying to type [not least
because "vkd3d" itself is an unwieldy name.] This is also a motivation for
shortening "instruction" to "instr".
* The "vkd3d_instruction" is increasingly growing from a simple parsed
representation of sm4 bytecode, to a proper IR in its own right—e.g. we are
using it for sm1 and sm6, are performing passes over it, and we have plans to
extend its scope further, e.g. to HLSL compilation. Give it a name that
reflects and clearly communicates what it is.
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/264
Redo of !1857, as suggested, the plan is to split original MR in half, breadcrumbs in first (this) MR, and address edit in another.
The changes are mostly cleanup (formatting, renaming, unused variables, missing free).
Visually, it hasn't changed from original MR, part 1 changes are:

And part 2:

Part 2 branch can be found [here](https://gitlab.winehq.org/vt/wine/-/commits/fd-navbar-part2).
Requires !2068, otherwise if application doesn't request comctl v6 (e.g. qapitrace), navigation bar will look like this:

Closes:
- https://bugs.winehq.org/show_bug.cgi?id=29912
- https://bugs.winehq.org/show_bug.cgi?id=54812
- https://bugs.winehq.org/show_bug.cgi?id=50338 (partially? fully with address edit?)
MR changes:
- v2
- changed the gap between buttons to be scaled with DPI
- v3
- DPI scale the gap in layout calculation in breadcrumbs commit, missed it earlier
- remove padding from layout calculation, `GetWindowRect` was unintentionally returning double padding, 4px from `hspacing` in `itemdlg.c:update_layout`, and another 4px from somewhere else
- drop `comdlg32: Keep IExplorerBrowser in IFileDialog focused after Backspace.` hack
- retain IExplorerBrowser view focus in IFileDialog when creating new view
- redirect navigation bar buttons focus back to the previous window
- v4
- rename background to frame
- calculate overflow button width into separate variable, [will come in handy in part 2](https://gitlab.winehq.org/vt/wine/-/commit/998b6987500edda02d6a9177c7da2…
- simplify show-at-least-N-crumbs logic
- drop `comdlg32: Prevent arrow navigation of IFileDialog navigation bar buttons.`
- drop `comdlg32: Don't paint focus rect in IFileDialog navigation bar buttons.`
- add tab navigation
- avoid taking button focus by sending `VK_SPACE` instead
- v5
- rebase on current master
- rename `NAVBAR_ButtonProc`/`BUTTON_SUBCLASS_ID` into `NAVBAR_PushButtonProc`/`PUSHBUTTON_SUBCLASS_ID`, describes it more accurately
- remove brackets in `WM_LBUTTONDOWN`/`WM_LBUTTONDBLCLK` in `NAVBAR_PushButtonProc`, for some consistency, usually not placing them if I don't have to
- swap `SWP_NOSIZE | SWP_NOMOVE` to `SWP_NOMOVE | SWP_NOSIZE` in tab navigation commit, so that it matches the argument order
- add `LAYOUT_ITEMS_N` define for use in `BeginDeferWindowPos`, to update the number of items in a single place instead of 2 or 3
Description edits:
- v2
- Updated the changes image (by splitting it)
- Added MR changes
- v3
- Added description edits
- Updated the changes image again (forgot the overflow button change)
--
v6: comdlg32: Avoid taking focus on LMB click in IFileDialog navigation bar buttons.
comdlg32: Add tab navigation to IFileDialog navigation bar.
comdlg32: Retain IExplorerBrowser view focus in IFileDialog when creating new view.
comdlg32: Add breadcrumb overflow menu to IFileDialog navigation bar.
comdlg32: Add inner border to breadcrumbs in IFileDialog navigation bar.
comdlg32: Always show at least 2 crumbs in IFileDialog navigation bar.
comdlg32: Reuse address breadcrumbs in IFileDialog navigation bar.
comdlg32: Add address breadcrumbs to IFileDialog navigation bar.
comdlg32: Add go up button to IFileDialog navigation bar.
comdlg32: Add IFileDialog navigation bar control.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2993
This MR optimizes and makes correctness improvements to the window_surface flush implementation:
1. Implement a buffer queue to avoid constantly allocating new buffers.
2. Take into account the bounds of the window_surface flush and track per-buffer damage to reduce copying from the window_surface.
3. Copy from the window_surface only pixel data that lies within the flushed bounds. Maintain the latest contents for pixels outside these bounds, by copying them from the latest valid buffer.
4. Communicate damaged surface regions to the compositor to allow it to perform more efficient pixel data transfers (e.g., texture uploads).
Thanks!
--
v2: winewayland.drv: Send surface damage region to the compositor.
winewayland.drv: Update only the flushed bounds from the window_surface.
winewayland.drv: Track damaged buffer regions.
winewayland.drv: Use a buffer queue for window_surface.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3234
This replaces Wine's 14 copies of debugstr_hstring.
--
v4: include: Introduce wine_dbgstr_hstring and debugstr_hstring.
include: Use correct header guard name in winstring.h.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3157
vkd3d-shader/hlsl: Support evaluated expressions for sample count in multisampled textures declarations.
Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com>
--
v2: vkd3d-shader/hlsl: Disallow certain instruction types from constant expressions.
vkd3d-shader/hlsl: Support evaluated expressions for sample count in multisampled textures declarations.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/256
```
On Margate Sands.
I can connect
Nothing with nothing.
```
--
v4: vkd3d-shader/d3dbc: Scan for the maximum temporary register index.
vkd3d-shader: Record a global temporary count per sm4 shader.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/255
In a declaration with multiple variables, the variables must be created
before the initializer of the next variable is parsed. This is required
for initializers such as:
```
float a = 1, b = a, c = b + 1;
```
The solution is to parse the type information in the same rule as the first variable ('a' in this case) so that it can be declared before the parser reaches the initializer for the following variables.
To initialize the following variables, the type information is passed along from the first variable's struct parse_variable_def to the next and so on.
---
Solves https://bugs.winehq.org/show_bug.cgi?id=54484, pointed out by @nsivov.
--
v4: vkd3d-shader/hlsl: Declare vars individually when parsing struct declarations.
vkd3d-shader/hlsl: Declare vars individually when parsing regular declarations.
vkd3d-shader/hlsl: Split declare_vars().
tests: Test multiple variable initializers.
tests: Test semantics in uniform variables.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/250
On my Nvidia GeForce GTX 1050 Ti `ddxddy.shader_test` doesn't pass because of considerably different numeric results.
As Giovanni pointed out, this is because my GPU uses the fine derivate and not the coarse derivate to implement ddx() and ddy().
For this reason, the result for ddx|ddy() is quantized so that the test passes if the GPU uses either coarse or fine derivates.
Additionally, tests for both ddx_coarse|ddy_coarse() and ddx_fine|ddy_fine() are added, that expect a more precise result.
--
v4: vkd3d-shader/hlsl: Support fine derivates.
vkd3d-shader/hlsl: Support coarse derivates.
tests: Quantize regular and coarse derivate test results.
tests: Make ddx() and ddy() test behave correctly for shader models < 4.
tests: Test coarse and fine derivates.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/224
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.
--
v2: d3d10core/tests: Mark test failures specific to the Vulkan or GL renderers.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3232
> The part that doesn't thrill me is the fact that DXGI still directly accesses the VkQueue object, which I tend to see as an internal implementation detail to vkd3d. On the other hand it's nice that we don't need new API from vkd3d (even if, in the future, we were to need something other than vkQueueSubmit() and vkQueuePresentKHR()).
For what it's worth, it was a fairly explicit design decision early on to expose the underlying Vulkan objects for d3d12 devices and command queues, as well as to allow the creation of d3d12 resources on top of existing Vulkan images, for the purpose of interoperation with other Vulkan code. I.e., the idea is that it should be possible to integrate vkd3d into a larger Vulkan application to draw some parts using the d3d12 API, while everything else is drawn using Vulkan.
The internal queueing of command queue operations on the vkd3d level is unfortunate in that regard; ideally we just wouldn't do that. This MR could probably do a better job of explaining why we need to do that in some cases, and what kind of command queue operation sequences could result in out-of-order presentation.
If we're going to need to introduce a DXGI worker thread anyway, could we just make vkd3d_acquire_vk_queue() block until there are no longer any operations queued?
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3165#note_37779
Sub / Function can be on one line, but only if there's brackets.
```
| Storage_opt tFUNCTION Identifier ArgumentsDecl BodyStatements tEND tFUNCTION
```
This leads to sometimes to `link_statements` being called with `head` being NULL, probably because now the `:` can be parsed as `Statement` in `BodyStatements`.
Also note that this introduces another shift/reduce conflict, could be related, but I don't understand it well enough. Feedback would be appreciated, I'm still learning bison.
--
v3: vbscript: Support one-line sub/function.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3206
This MR optimizes and makes correctness improvements to the window_surface flush implementation:
1. Implement a buffer queue to avoid constantly allocating new buffers.
2. Take into account the bounds of the window_surface flush and track per-buffer damage to reduce copying from the window_surface.
3. Copy from the window_surface only pixel data that lies within the flushed bounds. Maintain the latest contents for pixels outside these bounds, by copying them from the latest valid buffer.
4. Communicate damaged surface regions to the compositor to allow it to perform more efficient pixel data transfers (e.g., texture uploads).
Thanks!
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3234
Shader Model 6 introduces a 16-bit float (half) type, and 16-bit and 64-bit integer types. Storing extra info in the type enum simplifies checking if a type is any integer, floating point or numeric type, and the declaration of SPIR-V types. The benefits depend on using enum vkd3d_data_type in the backend instead of vkd3d_shader_component_type.
Patch 2 is difficult to split because types typically flow through to vkd3d_spirv_get_type_id(), so partial changes would require new calls to conversion functions which would be deleted again later.
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/263
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