Any time CanConvert returns FALSE for the output parameter,
also return an appropriate failing result code.
This also adds tests for CanConvert.
--
v2: windowscodecs: Make values returned from CanConvert consistent
https://gitlab.winehq.org/wine/wine/-/merge_requests/7091
No reviews required.\
This is just to get the test results as seen by gitlab.\
MR will be cancelled afterwards.
--
v3: wininet/tests: Update issuer check for winehq.org certificate.
user32/tests: Add flaky_wine to some SetActiveWindow tests.
urlmon/tests: Expect "Upgrade, Keep-Alive" connection string.
urlmon/tests: Fix a test that fails after WineHQ updates.
secur32/tests: Mark some test results as broken on old Windows versions.
imm32/tests: Add todo_himc to some ImmTranslateMessage expected calls.
dnsapi/tests: Update tests for winehq.org DNS changes.
gitlab: Do not run the build script on each commit.
gitlab: Remove make -j options.
gitlab: Update configuration for the new Mac runner.
gitlab: Add 'build' tag on Linux build jobs.
secur32/tests: Update the tests to expect HTTP/2 headers.
secur32/tests: Update count for new winehq.org certificate.
secur32/tests: Switch to TLS 1.2 for connections to test.winehq.org.
secur32: Handle GNUTLS_MAC_AEAD.
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/7098
work is still in progress.
todo:
- ensure that all affected sources (i.e. C sources with any kind of assembly) are listed in either way for all architectures
- test Wine built with LTO
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7111
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=57076
I don't know if this is how native does it, but it makes intuitive sense to me that if we have a glyph in the requested font, we should use it, and this fixes the bug in question. This should avoid the possibility of regression in cases where font linking isn't needed. There is a possibility of regression in corner cases handled better by the earlier version of font linking.
--
v3: gdiplus: Use font linking only for missing glyphs.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7054
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=57076
I don't know if this is how native does it, but it makes intuitive sense to me that if we have a glyph in the requested font, we should use it, and this fixes the bug in question. This should avoid the possibility of regression in cases where font linking isn't needed. There is a possibility of regression in corner cases handled better by the earlier version of font linking.
--
v2: gdiplus: Use font linking only for missing glyphs.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7054
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=57076
I don't know if this is how native does it, but it makes intuitive sense to me that if we have a glyph in the requested font, we should use it, and this fixes the bug in question. This should avoid the possibility of regression in cases where font linking isn't needed. There is a possibility of regression in corner cases handled better by the earlier version of font linking.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7054
After the change to move the sync_gl_drawable call outside the win_data mutex in 54d82ed4, the X11 client rect used for determining whether we need to composite/clip the drawable can be out of sync with the win32 side. This would result in offscreening when unnecessary and vice-versa.
--
v3: winex11: Use the win32 client rect in needs_client_window_clipping.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7106