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.
3. avoid not needed TransformMatrixPoints
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)
--…
[View More]
v11: 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
[View Less]
This fixes a performance regression introduced during state redesign shortly after Wine 5.0.
Some games create a great amount of lights (around 1000 and growing) and touch them quite often. That results in each light being relayed to CS thread before each draw which is taking a great amount of time (performance drop in Nosferatu: The Wrath of Malachi from ~150 fps to ~10-15 at start location; that's with another unrelated regression related to streaming buffer management sorted out).
It is …
[View More]also possible to use bitmasks like for other states, but then with these lights amount even iterating over the full set of lights during stateblock apply leads to noticable performance drop.
With this patchset Nosferatu reaches ~180 fps on the same place (~115 on Windows on the same machine, with the difference being probably due to SWVP).
--
v4: wined3d: Use RB tree for storing lights.
wined3d: Track per light state changes in stateblock.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2833
[View Less]
Toolbar buttons won't adjust its size to fit the DPI setting. This two patches set a DPI-considered size to those buttons to make them look better in HiDPI.
Here are some comparisons on Wine with 192 DPI:

vs


vs
![…
[View More]item_dialog_after](/uploads/f74242d52dc461097368897982b0273b/item_dialog_after.png)
--
v2: comdlg32: Set a size for toolbar buttons of the file access dialog.
comdlg32: Calculate button height of toolbar with DPI for item dialog.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2849
[View Less]
Pass struct hlsl_constant_value to folding functions, in preparation for
creating the destination constant instruction from that value.
--
v2: vkd3d-shader/hlsl: Pass hlsl_constant_value and hlsl_type pointers to fold_nequal().
vkd3d-shader/hlsl: Pass hlsl_constant_value and hlsl_type pointers to fold_mul().
vkd3d-shader/hlsl: Pass hlsl_constant_value and hlsl_type pointers to fold_add().
vkd3d-shader/hlsl: Pass hlsl_constant_value and hlsl_type pointers to fold_neg().
…
[View More] vkd3d-shader/hlsl: Pass hlsl_constant_value and hlsl_type pointers to fold_cast().
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/205
[View Less]
Fix Cafe Stella (SteamID: 1829980) Flowchart crashes once there are 2 things on it.
--
v4: gdiplus: Support playing back pen custom end line cap.
gdiplus: Support playing back pen custom start line cap.
gdiplus: Support recording pen custom end line cap.
gdiplus: Support recording pen custom start line cap.
gdiplus/tests: Add pen custom line cap record and play back tests.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2870
We test once above that the source does not use the existing allocator, but then
implicitly release the allocator we are testing against (when the source assigns
a new allocator to the sink). As a result, these ok() statements were testing
that newly allocated allocators had a different address than the original
allocator, which of course sometimes fails.
Since we don't need to perform this test more than once anyway, just get rid of
the offending ok() statements.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2885
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 …
[View More]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.
--
v5: 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
[View Less]
From Microsoft documentation, [Using Side-by-Side Assemblies as a Resource][sxs-rsrc] outlines the significance of each reserved manifest resource ID.
Further investigation reveals the following:
1. `CREATEPROCESS_MANIFEST_RESOURCE_ID` (value: `1`): This is used for process-wide initial (`NULL`) activation context.
- **Usage documentation**: [Enabling an Assembly in an Application Without Extensions](https://learn.microsoft.com/en-us/windows/win32/sbscs/enabling-…
- **Intended …
[View More]container module type**: EXE only.
- **Lifetime of the associated activation context**: Alive until the process is terminated. Owned by system (NTDLL).
- **Isolation-aware**: No.
2. `ISOLATIONAWARE_MANIFEST_RESOURCE_ID` (value: `2`): This is used to specify the assembly manifest that the loader (Ldr) uses to resolve static imports. Also, this is used by isolation-aware wrappers defined in `*.inl` files included in the Windows SDK (`include\um`) when the `ISOLATION_AWARE_ENABLED` macro is defined as a nonzero value.
- **Usage documentation**: [Enabling an Assembly in an Application Hosting a DLL, Extension, or Control Panel](https://learn.microsoft.com/en-us/windows/win32/sbscs/enabling-an-as…
- **Intended container module type**: EXE and DLL.
- **Lifetime of the associated activation context**: Alive until the module is unloaded (e.g., via `FreeLibrary`). Owned by system (NTDLL).
- **Isolation-aware**: Yes.
3. `ISOLATIONAWARE_NOSTATICIMPORT_MANIFEST_RESOURCE_ID` (value: `3`): Ignored by the loader when resolving static imports. This is used by isolation-aware API wrappers defined in `*.inl` files included in the Windows SDK (`include\um`) when the `ISOLATION_AWARE_ENABLED` macro is defined as a nonzero value.
- **Usage documentation**: [IsolationAwareCleanup function][IsolationAwareCleanup]
- **Intended container module type**: EXE and DLL.
- **Lifetime of the associated activation context**: Alive until the application calls [`IsolationAwareCleanup`][IsolationAwareCleanup][^ia-cleanup-note]. Owned by the isolation-aware API wrapper library (part of the Windows SDK, rather than being a system DLL).
- **Isolation-aware**: Yes.
The `ISOLATION_AWARE_ENABLED` macro is documented in [Isolating Components][sxs-ic] as well as [Specifying a Default Activation Context][sxs-def-actctx]. When `ISOLATION_AWARE_ENABLED` macro is defined as a nonzero value, then the isolation-aware API wrapper library is enabled. The isolation-aware API wrapper library is responsible for:
- Creating (lazily) and destroying activation context (in `IsolationAwareCleanup`), if the manifest resource ID is `ISOLATIONAWARE_NOSTATICIMPORT_MANIFEST_RESOURCE_ID`.[^actctx-lifetime-remark]
- Note: the isolation-aware API wrapper library does not manage the activation context's lifetime and delegates the responsibility to the system loader if the manifest resource ID is `ISOLATIONAWARE_MANIFEST_RESOURCE_ID`.
- Intercepting Win32 API calls for automatic activation context activation. Each API wrapper activates the "isolation-aware" activation context (obtaining one if it did not exist) before calling the original procedure, and deactivates it before returning.
The isolation-aware wrappers may be either be defined inline, or compiled into static libraries that are linked into the final application executable.
From the information above as well as the tests included in this merge request, we can infer the following:
1. Although side-by-side awareness is a cross-cutting concern, the *activation* of activation contexts itself is *not* usually performed automatically by the system for the application (with the sole exception of process-wide activation context associated with `CREATEPROCESS_MANIFEST_RESOURCE_ID`, and static import resolution).
2. `ISOLATIONAWARE_NOSTATICIMPORT_MANIFEST_RESOURCE_ID` is treated like any other resource ID (from `0x0004` to `0xffff`) as far as the loader is concerned.
3. The resource ID of the manifest only concerns how the module containing the manifest intends to use the manifest. In fact, for DLLs that do not *statically* import symbols from side-by-side assemblies, the three resource IDs above are basically equivalent. A DLL can elect not to use manifest resources at all, and manage activation context and library loading by itself.
This is why I believe that this merge request is sufficient in completing the isolation-aware component support in Wine; the heavy lifting is done in the application side, not the system.
**EDIT**: Fix a few typos and unclear wording.
---
[^ia-cleanup-note]: According to the documentation, the application is presumably responsible for calling `IsolationAwareCleanup` from `DllMain` on `fdwReason = DLL_PROCESS_DETACH`.
[^actctx-lifetime-remark]: [IsolationAwareCleanup § Remarks](https://learn.microsoft.com/en-us/previous-versions/windows/deskto…, from Microsoft documentation.
[sxs-rsrc]: https://learn.microsoft.com/en-us/windows/win32/sbscs/using-side-by-side-as…
[IsolationAwareCleanup]: https://learn.microsoft.com/en-us/previous-versions/windows/desktop/legacy/…
[sxs-ic]: https://learn.microsoft.com/en-us/windows/win32/sbscs/isolating-components
[sxs-def-actctx]: https://learn.microsoft.com/en-us/windows/win32/sbscs/specifying-a-default-…
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=18889
--
v7: ntdll: Don't hard-code DLL manifest resource ID when looking up dependency assembly.
kernel32/tests: Test loading assembly manifest resource inside dependencies.
ntdll: Move ACTCTX lpResourceName validation to RtlCreateActivationContext.
kernel32/tests: Test setting lpResourceName to NULL for CreateActCtxW.
kernel32/tests: Remove test for ACTCTX_FLAG_HMODULE_VALID with hModule = NULL case.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2555
[View Less]
Block records are not processed; only the bitcode is validated.
--
v10: vkd3d-shader/dxil: Read and validate global abbreviated operands.
vkd3d-shader/dxil: Read and validate local abbreviated operands.
vkd3d-compiler: Introduce dxbc-dxil and dxbc-auto source types.
vkd3d-shader/dxbc: Introduce an option to autodetect the DXBC source type.
vkd3d-shader/dxil: Read and validate DXIL bitcode unabbreviated blocks.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/44
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.
3. avoid not needed TransformMatrixPoints
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)
--…
[View More]
v10: test: try to fix failing test on 32 bit
https://gitlab.winehq.org/wine/wine/-/merge_requests/2864
[View Less]
~~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-…
[View More]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
[View Less]
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 …
[View More]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
[View Less]
--
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)
--
…
[View More]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
[View Less]
--
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
This enables horizontal scrolling gestures/wheels (tested on macOS) in applications like IrfanView which handle WM_MOUSEHWHEEL.
Support will need to be added to common controls for horizontal scrolling to work in programs like Wine's explorer or regedit.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2880
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)
--
…
[View More]v8: gdiplus: Improve performance of DrawImagePointsRect by avoid TransformMatrixPoints
gdiplus: Improve performance of GdipDrawImagePointsRect
gdiplus: use iterator instead calculate pointer position every time
gdiplus: limit calculating transformation points to resampling
https://gitlab.winehq.org/wine/wine/-/merge_requests/2864
[View Less]
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)
--
…
[View More]v7: gdiplus: Improve performance of DrawImagePointsRect by avoid TransformMatrixPoints
https://gitlab.winehq.org/wine/wine/-/merge_requests/2864
[View Less]
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)
--
…
[View More]v6: gdiplus: Improve performance of ZZGdipDrawImagePointsRect by avoid TransformMatrixPoints
https://gitlab.winehq.org/wine/wine/-/merge_requests/2864
[View Less]
--
v3: vkd3d-shader/tpf: Write out comparison mode sampler declarations and corresponding sampling instruction.
vkd3d-shader/hlsl: Parse SampleCmp() method.
vkd3d-shader/hlsl: Parse SamplerComparisonState objects.
vkd3d-shader/hlsl: Use a function table for object methods handlers.
vkd3d-shader/hlsl: Move object type checks to methods handlers.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/206
This fixes a performance regression introduced during state redesign shortly after Wine 5.0.
Some games create a great amount of lights (around 1000 and growing) and touch them quite often. That results in each light being relayed to CS thread before each draw which is taking a great amount of time (performance drop in Nosferatu: The Wrath of Malachi from ~150 fps to ~10-15 at start location; that's with another unrelated regression related to streaming buffer management sorted out).
It is …
[View More]also possible to use bitmasks like for other states, but then with these lights amount even iterating over the full set of lights during stateblock apply leads to noticable performance drop.
With this patchset Nosferatu reaches ~180 fps on the same place (~115 on Windows on the same machine, with the difference being probably due to SWVP).
--
v3: wined3d: Use RB tree for storing lights.
wined3d: Track per light state changes in stateblock.
wined3d: Only set changed.lights if wined3d_light_state_enable_light() changed state.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2833
[View Less]
Adds the tray icons implementation based on org.kde.StatusNotifierItem interface usage. Does allow restarting StatusNotifierWatcher object, but will fallback to XEMBED or internal tray, if wine gets initialized when there is no StatusNotifierWatcher object registered.
--
v14: winesni.drv: implement basic balloon notification support
explorer: add winesni.drv tray implementation support
winesni.drv: add KDE StatusNotifierItem implementation for tray
https://gitlab.winehq.org/wine/wine/-/merge_requests/2808
Fix Cafe Stella (SteamID: 1829980) Flowchart crashes once there are 2 things on it.
--
v3: gdiplus: Support playing back pen custom end line cap.
gdiplus: Support playing back pen custom start line cap.
gdiplus: Support recording pen custom end line cap.
gdiplus: Support recording pen custom start line cap.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2870
Adds the tray icons implementation based on org.kde.StatusNotifierItem interface usage. Does allow restarting StatusNotifierWatcher object, but will fallback to XEMBED or internal tray, if wine gets initialized when there is no StatusNotifierWatcher object registered.
--
v13: configure: fix winesni.drv not getting disabled
winesni.drv: implement basic balloon notification support
https://gitlab.winehq.org/wine/wine/-/merge_requests/2808
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.
--
v5: gdiplus: Improve performance of GdipDrawImagePointsRect
gdiplus: Improve performance of GdipDrawImagePointsRect
gdiplus: Improve …
[View More]performance of GdipDrawImagePointsRect
https://gitlab.winehq.org/wine/wine/-/merge_requests/2864
[View Less]
gdip_format_string doesn't write newline characters. It writes line by line making sure to skip the newline characters. This means we can resolve this issue(at least as far gdiplus is concerned) without concerning ourselves with the issue in GetTextExtentExPointW(which should be dealt with as a different bug).
This patch implements a fix but there might be possible improvements in the code so yeah, input is most welcome.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=54962
Signed-off-by: …
[View More]David Kahurani <k.kahurani(a)gmail.com>
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2865
[View Less]
--
v12: vkd3d-shader/ir: Normalise signatures and input/output registers to the Shader Model 6 pattern.
vkd3d-shader/ir: Eliminate struct vkd3d_shader_normaliser.
vkd3d-shader/spirv: Support emitting multi-dimensional array variables.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/181
Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com>
--
v12: tests: Add RWBuffer writing test.
tests: Add support for UAV buffers in the d3d11 runner.
tests: Add support for UAV buffers to d3d12 runner.
tests: Rename readback helper to be more generic.
tests: Add support for UAV buffers in Vulkan runner.
vkd3d-shader/hlsl: Improve UAV format type checking for buffer types.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/193
Otherwise, it is possible that the register used by the temp is
overridden by a subsequent instruction within the same loop.
--
v2: vkd3d-shader/hlsl: Extend the liveness of nodes produced outside loops.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/208
~~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-…
[View More]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!
--
v11: vkd3d-shader/hlsl: Add support for SampleGrad() method
tests: Add a test for SampleGrad() method
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/184
[View Less]
--
v2: windows.gaming.input: Query IGameController interface in TryGetFactoryControllerFromGameController.
dinput/tests: Test that FromGameController also works with IRawGameController.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2873
This fixes a performance regression introduced during state redesign shortly after Wine 5.0.
Some games create a great amount of lights (around 1000 and growing) and touch them quite often. That results in each light being relayed to CS thread before each draw which is taking a great amount of time (performance drop in Nosferatu: The Wrath of Malachi from ~150 fps to ~10-15 at start location; that's with another unrelated regression related to streaming buffer management sorted out).
It is …
[View More]also possible to use bitmasks like for other states, but then with these lights amount even iterating over the full set of lights during stateblock apply leads to noticable performance drop.
With this patchset Nosferatu reaches ~180 fps on the same place (~115 on Windows on the same machine, with the difference being probably due to SWVP).
--
v2: wined3d: Use RB tree for storing lights.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2833
[View Less]
Fix Cafe Stella (SteamID: 1829980) Flowchart crashes once there are 2 things on it.
--
v2: gdiplus: Support playing back pen custom end line cap.
gdiplus: Support playing back pen custom start line cap.
gdiplus: Support recording pen custom end line cap.
gdiplus: Support recording pen custom start line cap.
gdiplus/tests: Add pen custom line cap record and play back tests.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2870
Adds the tray icons implementation based on org.kde.StatusNotifierItem interface usage. Does allow restarting StatusNotifierWatcher object, but will fallback to XEMBED or internal tray, if wine gets initialized when there is no StatusNotifierWatcher object registered.
--
v12: configure: fix winesni.drv not getting disabled
winesni.drv: implement basic balloon notification support
explorer: add winesni.drv tray implementation support
winesni.drv: add KDE …
[View More]StatusNotifierItem implementation for tray
https://gitlab.winehq.org/wine/wine/-/merge_requests/2808
[View Less]
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.
--
v4: gdiplus: Improve performance of GdipDrawImagePointsRect
https://gitlab.winehq.org/wine/wine/-/merge_requests/2864
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.
--
v3: gdiplus: Improve performance of GdipDrawImagePointsRect
https://gitlab.winehq.org/wine/wine/-/merge_requests/2864
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.
--
v2: gdiplus: Improve performance of GdipDrawImagePointsRect
gdiplus: Improve performance of GdipDrawImagePointsRect
gdiplus: Improve …
[View More]performance of GdipDrawImagePointsRect
https://gitlab.winehq.org/wine/wine/-/merge_requests/2864
[View Less]
On Fri May 19 21:00:14 2023 +0000, Esme Povirk wrote:
> My expectation is that, because Windows ships with Courier New, this
> would never happen on real Windows. It doesn't matter what native does
> when you run it on Wine or a Windows install without the font, because
> application developers will never encounter that situation in testing
> and aren't going to write applications expecting it.
> It's not going to be fully accurate behavior regardless, so why not do
> what …
[View More]the function is supposed to do and give the application a monospace font?
In Wine we have `Courier` font, which we could use:
https://gitlab.winehq.org/wine/wine/-/tree/master/fonts
I don't know what is the difference between Wine's `Courier` and Microsoft `Courier`.
Here is the comparison of `Courier New` and `Courier`:
http://www.identifont.com/differences?first=Courier&second=Courier+New&q=Go
Here is git history of Courier font:
```
$ git log courier.ttf
commit 40166848a7944383a4cfdaac9b18bd03fbb2b4f9
Author: Michael Stefaniuc <mstefani(a)winehq.org>
Date: Thu Sep 28 00:23:42 2017 +0200
fonts: Increase the Em size to fix a build failure with freetype 2.8.1.
Freetype 2.8.1 implemented the stricter Em bounds from OpenType 1.8.2
which require a minimum Em size of 16.
Signed-off-by: Michael Stefaniuc <mstefani(a)winehq.org>
Signed-off-by: Alexandre Julliard <julliard(a)winehq.org>
commit 80a17baf20da4620394f8832f6221edf45b7a0f0
Author: Alexandre Julliard <julliard(a)winehq.org>
Date: Thu Jul 11 15:29:19 2013 +0200
fonts: Update fonts with a more recent fontforge.
commit 994f74fb46285130cc63784449176c748cfdfaaf
Author: Alexandre Julliard <julliard(a)winehq.org>
Date: Thu Jul 11 11:54:28 2013 +0200
fonts: Add some missing Cyrillic glyphs to the Courier font.
commit a926bfdb061ffcdc3c6f88b29fca614f9f12fa78
Author: Alexandre Julliard <julliard(a)winehq.org>
Date: Wed Jan 25 19:16:25 2012 +0100
fonts: Add some missing glyphs in the Courier font.
commit 8330e11ca743c861c325bc772820a94ac2441c08
Author: Alexandre Julliard <julliard(a)winehq.org>
Date: Fri Feb 20 15:17:20 2009 +0100
fonts: Re-generate fonts using the "official" fontforge version.
commit 0f2cb23c7d5df22f9ff30e40afb4d6de03e03dae
Author: Aurimas Fischer <aurimas(a)gmail.com>
Date: Mon Mar 24 16:50:06 2008 +0200
fonts: Added/updated all (9x2) Lithuanian glyphs.
commit 8ad6049ac642bf61d338e0c2094b9a0b9a2f51bd
Author: Alexandre Julliard <julliard(a)winehq.org>
Date: Sat Mar 22 21:23:56 2008 +0100
fonts: Store the generated TrueType fonts in the repository, and rebuild them only in maintainer mode.
```
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2850#note_33314
[View Less]
Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com>
--
v11: tests: Add RWBuffer writing test.
tests: Add support for UAV buffers in the d3d11 runner.
tests: Add support for UAV buffers to d3d12 runner.
tests: Rename readback helper to be more generic.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/193
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 …
[View More]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.
--
v3: winewayland.drv: Update desktop window size on display changes.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2712
[View Less]
Find only supports one Column to filter on.
The parser for this will be the same for both Find/Filter with the only different
is the Filter supports multiple columns.
In trying to keep this patch small, only WSTR/BSTR/Integer have been supported. (The Common cases).
--
v2: msado15: Implement _Recordset Find
https://gitlab.winehq.org/wine/wine/-/merge_requests/2498
--
v2: vkd3d-shader/tpf: Write out comparison mode sampler declarations and corresponding sampling instruction.
vkd3d-shader/hlsl: Parse SampleCmp() method.
vkd3d-shader/hlsl: Parse SamplerComparisonState objects.
vkd3d-shader/hlsl: Use a function table for object methods handlers.
vkd3d-shader/hlsl: Move object type checks to methods handlers.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/206
> If you mean setting `O_NONBLOCK` on `server`, that would cause `accept` to return `EWOULDBLOCK` or `EAGAIN`.
No, I mean you can set O_NONBLOCK on "client", i.e. the socket that calls connect().
> By "clean up", do you mean only calling `WaitForSingleObject` on it, or is there more that I would need to do?
Wait for it and close the handle. It should be unnecessary if you just use nonblocking i/o with the socket, though.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2786#note_33265
> ~~Yes,~~ `SO_REUSEADDR` is a valid option on AF_UNIX sockets and is supported by this patch. I'll add a test for it. It looks like this is only true for abstract AF_UNIX sockets, which are expressly unsupported due to Windows' own lack of support for them.
Okay, I think I was assuming that "unbinding" meant doing the opposite of bind(), rather than "allowing other sockets to use that address". It'd be nice to have some tests for that functionality, then:
* test that trying to use the …
[View More]same address *without* deleting the socket fails (even if you close the socket handle? That part is very surprising to me.)
* test that trying to use the same address after deleting the socket succeeds, which currently isn't actually tested.
* Can the socket be used normally after deleting it?
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2786#note_33264
[View Less]
On Fri May 19 04:17:50 2023 +0000, Ally Sommers wrote:
> That's true, but `PATH_MAX` is 4096 on my system, while `sun_path` is a
> `char[108]`. The path returned by `wine_get_unix_file_name` can very
> easily exceed that. Thus a vararg is needed to conditionally pass the
> Unix path to wineserver if we're dealing with an AF_UNIX socket.
I still don't understand the issue. The sockaddr we pass to the server is already variable-sized. It's passed as variable-sized input data, using …
[View More]the "ioctl" request, with the code IOCTL_AFD_BIND. Why is sockaddr_un any different from sockaddr_in?
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2786#note_33263
[View Less]