This consolidates the two separate `CGImage`s (`colorImage` and `shapeImage`) previously used in `WineContentView` into a single `IOSurface` that also holds the window mask information in its alpha channel now.
The alpha channel is now being updated in `macdrv_surface_flush`, whenever the shape changes (and stores that change for the next update, to also keep the front buffer in sync).
This reduces the delay from setting a `CGImage` to a layer from 50ms to about 1.5ms in the `IOSurface` case (also accounting for `vImageSelectChannels_ARGB8888` operation).
Based on a patch by @bshanks.
I am already putting it out for feedback, but I will so some more testing to see how the performance impact of this is and do more exhaustive testing with shaped windows.
Ideally the double buffer solution can be avoided as well... Also the `HBITMAP` for the windows is currently backed by a `CGDataProviderRef` and could also become an `IOSurface` I believe.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7938
1. For %fs/fsbase the patch follows the macOS logic with LDT descriptor registration and Linux with switching. One notable difference is that on 32->64 transition we set %fs to GSEL(GUFS32_SEL, SEL_UPL) before restoring fsbase, otherwise FreeBSD will just revert it by reloading the selector [at the first opportunity](https://github.com/freebsd/freebsd-src/blob/5673462af5330df207…. GSEL(GUFS32_SEL, SEL_UPL) is the default %fs value on FreeBSD and is special-cased to save/restore actual fsbase value to/from PCB.
2. I was told we could get rid of fsbase glitches in signal handlers by blocking signals with [sigfastblock(2)](https://man.freebsd.org/cgi/man.cgi?query=sigfastblock) between %fs reset to the default value and fsbase reset to pthread_teb. This is currently a part of internal API for libthr, which could be exposed as pthread_signal_block_np for Wine. I'm on the fence whether it's worth it.
3. I fully admit I have no idea what registers are worth preserving around fallback sysarch(AMD64_SET_FSBASE) syscalls and whether it's appropriate to push those registers to stack. ("Kernel" stack should be fine, I assume?) Syscalls definitely clobber r8-r11.
4. For %ss see https://lkml.org/lkml/2015/4/24/216. FreeBSD doesn't have a similar workaround in the kernel, so it goes into Wine.
--
v5: ntdll: Unbreak new wow64 mode on FreeBSD.
https://gitlab.winehq.org/wine/wine/-/merge_requests/8073
1. For %fs/fsbase the patch follows the macOS logic with LDT descriptor registration and Linux with switching. One notable difference is that on 32->64 transition we set %fs to GSEL(GUFS32_SEL, SEL_UPL) before restoring fsbase, otherwise FreeBSD will just revert it by reloading the selector [at the first opportunity](https://github.com/freebsd/freebsd-src/blob/5673462af5330df207…. GSEL(GUFS32_SEL, SEL_UPL) is the default %fs value on FreeBSD and is special-cased to save/restore actual fsbase value to/from PCB.
2. I was told we could get rid of fsbase glitches in signal handlers by blocking signals with [sigfastblock(2)](https://man.freebsd.org/cgi/man.cgi?query=sigfastblock) between %fs reset to the default value and fsbase reset to pthread_teb. This is currently a part of internal API for libthr, which could be exposed as pthread_signal_block_np for Wine. I'm on the fence whether it's worth it.
3. I fully admit I have no idea what registers are worth preserving around fallback sysarch(AMD64_SET_FSBASE) syscalls and whether it's appropriate to push those registers to stack. ("Kernel" stack should be fine, I assume?) Syscalls definitely clobber r8-r11.
4. For %ss see https://lkml.org/lkml/2015/4/24/216. FreeBSD doesn't have a similar workaround in the kernel, so it goes into Wine.
--
v4: ntdll: Unbreak new wow64 mode on FreeBSD.
https://gitlab.winehq.org/wine/wine/-/merge_requests/8073
> There is probably some tiny DVD somewhere in the world that will still be misdetected, but I'm not sure that issuing SCSI commands to the drive to try to determine the disc type would be any more reliable.
To support an app that is most likely going to issue DVD ioctls, checking by using a DVD ioctl seems preferable.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7747#note_104243
--
v2: wineandroid: Use win32u for EGL display and pixel formats.
winewayland: Use win32u for EGL display and pixel formats.
win32u: Implement OpenGL pixel formats over EGL configs.
win32u: Introduce an EGL opengl_driver_function table.
winewayland: Use the EGL display opened from win32u.
wineandroid: Use the EGL display opened from win32u.
win32u: Open and initialize an EGL platform display.
https://gitlab.winehq.org/wine/wine/-/merge_requests/8115
And a couple of other minor and (hopefully) harmless changes, in preparation for !8079 as it would otherwise grow large.
The main thing here is the introduction of _MOTIF_WM_HINTS into the state tracker, changing the property can trigger unexpected ConfigureNotify events and we will need to serialize its updates with other _NET_WM_STATE and window config requests in order to avoid getting surprised and confused.
It will also later be useful to be able to track further consequences of _MOTIF_WM_HINTS changes on Mutter-based window managers, such as a ReparentNotify > UnmapNotify > FocusOut > MapNotify > FocusIn > ConfigureNotify event sequence, to eventually ignore the transient focus loss and avoid changing Win32 foreground window during it.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/8123