Since we're checking the child window clipping rules it is possible
that a toplevel window also has an onscreen client window, for instance
if the window wasn't created with WS_CLIPCHILDREN. The last window to
present between the parent and its children should be visible.
GDI blits always happen over the toplevel window, and we need to use
IncludeInferiors to make sure it goes through any onscreen client window
that is otherwise hiding the toplevel pixels.
It should be safe to use that flag wrt other child windows, as we also
set the clipping region to exclude the area that should be obscured by
any sibling.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=57661
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7141
--
v3: server: When renaming, only fstat the source once.
server: Remove source when renaming to a hardlink of itself.
kernel32/tests: Test renaming a file into a hardlink of itself.
kernel32/tests: Use FindClose instead of CloseHandle when closing
https://gitlab.winehq.org/wine/wine/-/merge_requests/6855
When the window manager moves windows offscreen, the Win32 config is
explicitly kept out of sync. We need to handle that case when the Win32
config changes, to avoid forcefully moving the windows back on screen.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=57652
Since 895ca2eda64f506b936999cdd8f14e224eef6a7f the window position might
be out of sync between Win32 and X if the X window manager has moved it
offscreen.
Then b936f7426e33508538f48f7d20e7d7cb47cc1f32 ignored size and position
changes, trying to avoid triggering requests that would force the X
window position to match the Win32 state.
However, the X visible rect might change on window style adjustments,
and not from a application-requested size change, and we need to request
these changes to the X server.
The SWP flags should be handled in win32u already and the window rect
position and size should not have changed if SWP_NOSIZE | SWP_NOMOVE
were set by the application.
What we need to do is to mind that the X window position might be out
of sync, and adjust the request to take the eventual offscreen position
into account.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7140
If `<arch>_CFLAGS`/`<arch>_LDFLAGS` are passed to configure they are ignored and replaced with the default flags. This prefers the user-provided flags if any, and falls back to `CROSSCFLAGS` / `CROSSLDLAGS` then to the default flags.
--
v2: configure: Use per-architecture cross flags if they are provided.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7139
On Sun Jan 12 20:25:27 2025 +0000, Nikolay Sivov wrote:
> Do we need this intersection check at all?
I believe we do. The code in `media_engine_transfer_d3d11` performs a `CopySubresourceRegion` directly to the application supplied texture, which only supports copy; it doesn't support any stretch. So `media_engine_transfer_d3d11` is used as an optimisation for when the application supplied texture has the same (or larger) dimensions as the output sample from the MF pipeline.
This check ensures we fallback when stretching is required. The fallback writes to a media engine supplied texture, that is then applied to a quad that can be stretched (before being written to the application texture).
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7124#note_91816