Windows gives this content special protection from being painted over, by some means that I have not investigated yet.
Emulate this protection for the trivial case of an InvalidateRect(...); call on the parent window.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3416
- Make it present some frames
- Make it check that the frames are from the new device, instead of checking TerminateDevice count; fixes https://bugs.winehq.org/show_bug.cgi?id=55649
- Make it check for and avoid some absurd crash on Windows
I tried everything I could think of, but Windows absolutely refuses to present a frame after changing the D3D device, instead choosing to return various absurd errors (segfaults, deadlocks, out of memory, etc). I suspect the VMR9 is haunted.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3970
This series:
- fixes a couple of issues in mach-o modules support
(getting information from system modules in wow setups,
machine information...)
- stops hiding information in some fields between dbghelp
and winedbg (using an extensible solution, where more
information can be shared in the future)
- display elf/mach-o in winedbg (previously mach-o was
reported as elf)
- display PE native vs builtin module information in winedbg
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3975
Rainbow 6 Siege and some other games require this. Type is printed in the FIXME to determine which type the application requires.
--
v8: gdi32: Add stub for D3DKMTQueryAdapterInfo.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3777