~~This one's marked as a draft, as there seems to be a blocker with the method parameters.~~
~~The first commit totally works, _if_ the ddx/ddy parameters are literals - they do _not_ work when passing a variable of any kind. The test comes from tests/d3d12.c, so I'm mostly just trying to migrate that to the HLSL test suite, but it currently hits an assert before we get to the resource load (which does eventually work) and I'm not sure what's causing it:~~
```
vkd3d-compiler: libs/vkd3d-shader/tpf.c:3190: sm4_register_from_node: Assertion `instr->reg.allocated' failed.
```
~~Seems like it's surprised when we try to load from the constant buffer maybe?~~ Fixed!
--
v12: vkd3d-shader/hlsl: Add support for SampleGrad() method
tests: Add a test for SampleGrad() method
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/184
This MR introduces the driver mechanisms to handle dynamic events from the Wayland compositor, using wl_output events as the guiding use case (i.e., we want to update the win32u display settings when the host settings change).
In this design we create a dedicated thread to read and dispatch Wayland events received from the compositor. If a Wayland event handler wants some code to be run in the context of a particular HWND's thread, it can add an internal event to a custom queue we have for each (GUI enabled) thread. The ProcessEvents driver callback processes internal events from that queue. In order to wake up waiting threads we use a pipe to notify about new internal events, with the read end acting as the thread's host queue fd. This is similar to how winemac.drv works.
We use the aforementioned mechanisms to queue win32u display device updates to the desktop window thread. Since there are many pieces that need to fall into place, this MR gradually reaches the final design:
1. We first introduce the dedicated read/dispatch thread and handle events (and also display device updates if in the desktop process) in that thread.
2. We ensure access to Wayland output information is thread-safe and consistent (since in step 3 we will need to access it from a different thread).
3. We finally introduce per-thread internal event queues and, if we are in the desktop process, queue the display device update to the desktop window thread internal event queue. Note that the main portion of the wl_output event code is still handled in the dedicated read/dispatch thread.
--
v4: winewayland.drv: Update desktop window size on display changes.
winewayland.drv: Update display devices from the desktop window thread.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2712
--
v3: dsound: Avoid division by zero when calculating Doppler shift.
dsound: Change the speed of sound to 360.
dsound: Enable Doppler shift.
dsound/tests: Add tests for Doppler shift.
dsound: Store the frequency of 3D buffers separately.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2722
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=53947
Improve performance of GdipDrawImagePointsRect by:
1. avoiding multiplication and use addition where it is possible.
2. avoid calculating `GdipInvertMatrix` if it is not used
It gives noticible speed improvement.
I divided MR to several commits, to better undestand what is going on.
Application for testing (it needs logo.jpg file):
[gdiplusdrawimagepoints.exe](/uploads/545ff7d8ab1d60386366f64999346825/gdiplusdrawimagepoints.exe)
--
v9: gdiplus: Improve performance of DrawImagePointsRect by avoid TransformMatrixPoints
gdiplus: use float increment instead of calculation to impove perf
gdiplus: use iterator instead calculate pointer position every time
https://gitlab.winehq.org/wine/wine/-/merge_requests/2864
--
v2: dsound: Avoid division by zero when calculating Doppler shift.
dsound/tests: Test Doppler shift with zero distance.
dsound: Change the speed of sound to 360.
dsound: Enable Doppler shift.
dsound/tests: Add tests for Doppler shift.
dsound: Store the frequency of 3D buffers separately.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2722