Instead of using glBufferSubData(). In practice, this means that we will either
discard and rename the BO (if it's still in use) or write directly into it (if
not).
This improves performance drastically on NVidia GL drivers.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=53408
Analogous to the Vulkan backend.
This is not particularly impactful, though, since it only affects buffer-buffer
copies in the case where ARB_copy_buffer is not supported.
The tests are actually racy, and the async operation is cancellable in
a very short period of time after its creation, but before it started
executing.
This will be hard to test precisely and it's not related to dinput tests
in any way. Let's remove this to fix some spurious Windows failures.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=54283
To match combase allocations, as for instance we're freeing pointers
returned from InternalIrotRevoke, which are allocated using combase
MIDL_user_allocate.
Some window managers have trouble moving fullscreen windows to another monitor. For example, KWin
doesn't allow moving windows with _NET_WM_STATE_FULLSCREEN set. FVWM used by TestBots keeps
the size for fullscreen windows after they are moved to another monitor and when the window is also
fullscreen on the new monitor, which could be a bug in FVWM. But let's work around this in the tests
as well. The changed tests don't need created windows being fullscreen at the start.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=54172
To ensure a seamless transition between value names, we try loading the
registry value from FontFamily first and FontPitchFamily second.
Any changes to the console font family are saved to the new value name.
SetWindowIcon can pass an icon as a parameter, but in that case
NtUserGetIconInfo is never called, so the icon info is never filled.
Fixes a regression introduced by 3eb944c0a7.
Signed-off-by: Gabriel Ivăncescu <gabrielopcode@gmail.com>
There are cases in Windows10+ where the WM_PASTE message doesn't paste
the content of the clipboard.
This appeared in testing:
- almost always just after (for a couple of milliseconds) setting new
content into the clipboard and closing it.
- in some unrelated rare occasions (like once for 400 runs).
It looks like another (installed) process had opened the clipboard and
forbids the paste command.
As WM_PASTE doesn't return success/error status, workaround it by
wrapping the WM_PASTE command into a helper, and retry when the
clipboard's content hasn't been pasted.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=53276
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=53277
Signed-off-by: Eric Pouech <eric.pouech@gmail.com>
As the clipboard is a shared resource, we cannot expect that
no other app hasn't openeded it.
So wrap clipboard access with a retry feature in case of failure.
Signed-off-by: Eric Pouech <eric.pouech@gmail.com>
There are cases in Windows10+ where the WM_PASTE message doesn't paste
the content of the clipboard.
This appeared in testing:
- almost always just after (for a couple of milliseconds) setting new
content into the clipboard and closing it.
- in some unrelated rare occasions (like once for 400 runs).
It looks like another (installed) process had opened the clipboard and
forbids the paste command.
As WM_PASTE doesn't return success/error status, workaround it by
wrapping the WM_PASTE command into a helper, and retry when the
clipboard's content hasn't been pasted.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=53276
Signed-off-by: Eric Pouech <eric.pouech@gmail.com>
As the clipboard is a shared resource, we cannot expect that
no other app hasn't openeded it.
So wrap clipboard access with a retry feature in case of failure.
Signed-off-by: Eric Pouech <eric.pouech@gmail.com>
