January 2024 - Wine-gitlab - list.winehq.org

[PATCH 0/1] MR3109: imm32: Don't export internal variables.
by Alex Henrie (＠alexhenrie) 24 Jan '25

24 Jan '25

-- https://gitlab.winehq.org/wine/wine/-/merge_requests/3109

6 22

[PATCH v2 0/2] MR825: winex11.drv: optimize repeated ClipCursor calls
by Jan Klötzke 17 Dec '24

17 Dec '24

At least Doom 64 calls ClipCursor() with identical parameters repeatedly, which seems to cause a considerable overhead. Together with high polling rate mouse input this causes the game to almost freeze while the mouse is being moved. So if the clipping did not change we can bail out early because it will not cause any observable difference anyway. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=46976 Signed-off-by: Jan Klötzke <jan(a)kloetzke.net> -- v2: winex11.drv: optimize repeated ClipCursor calls winex11.drv: create win32 clipping window only once https://gitlab.winehq.org/wine/wine/-/merge_requests/825

4 8

[PATCH v2 0/2] MR475: server: Fix object name resolution of \Device\Null.
by Jinoh Kang (＠iamahuman) 05 Dec '24

05 Dec '24

This simplifies future tests that check for object name of devices. -- v2: server: Fix object name resolution of \Device\Null. server: Make explicit the ownership of the unix_name buffer. https://gitlab.winehq.org/wine/wine/-/merge_requests/475

3 4

[PATCH v2 0/3] MR698: d2d1: Implement transform graph.
by Ziqing Hui (＠zhui) 30 Nov '24

30 Nov '24

-- v2: d2d1: Implement nodes connection for ID2D1TransformGraph. d2d1: Implement nodes adding and removal for ID2D1TransformGraph. d2d1/tests: Add more tests for ID2D1TransformGraph. https://gitlab.winehq.org/wine/wine/-/merge_requests/698

2 6

[PATCH 0/1] MR3226: comctl32/edit: Scroll caret on Ctrl+A.
by Vladislav Timonin (＠vt) 28 Nov '24

28 Nov '24

Every other use of `EDIT_EM_SetSel` updates caret position by calling `EDIT_EM_ScrollCaret` or `EDIT_SetCaretPos`. Fixes caret blinking in the middle when selecting all text. ![changes](/uploads/019bce6c12e0378d391e1253ecbaf9c6/changes.png) -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3226

4 6

[PATCH 0/1] MR1121: winhttp: Fix missing reference upcount
by Yuan Yao (＠yaoyuan.0553) 28 Nov '24

28 Nov '24

The reference count of host is supposed to go up by one in netconn_create. The missing ref increment causes error handling paths where netconn_close or release_host is called to prematurely decrement the ref count of host to zero. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1121

4 6

[PATCH v5 0/2] MR3718: dwrite: Fix incorrect position of glyph when using BitmapRenderTarget in HiDPI
by Tingzhong Luo (＠tzluo) 26 Nov '24

26 Nov '24

The "GdiInterop" is a sample application (source code is avaiable in [Github][source_code], relative guide in [MSDN][msdn_guide]) that demostracts how to display DirectWrite text on a GDI surface. After set dpi to 168 in `winecfg`, and run sample application with wine, the font size is normal, but the position of glyph is incorrect. | Dpi: 96 | Dpi: 168 | |:----------------:|:-----------------:| | ![ss1][sc_96dpi] | ![ss2][sc_168dpi] | There is the sample application after compile: [Release_x64.tar.gz](/uploads/c70e32824efcaa5d16ab39bbb4b86e30/Release_x64.tar.gz) After change transform matrix that pass to `IDWriteFactory7_CreateGlyphRunAnalysis`, it can display glyph correctly. [source_code]: https://github.com/microsoft/Windows-classic-samples/blob/main/Samples/Win7… [msdn_guide]: https://learn.microsoft.com/en-us/windows/win32/directwrite/render-to-a-gdi… [sc_96dpi]: /uploads/59cc343cfaa025f4ff4c32a84ab8cfeb/图片.png [sc_168dpi]: /uploads/938be653362bb6ac58471b69ab66099a/图片.png -- v5: dwrite: Fix incorrect position of glyph when rendering with BitmapRenderTarget in HiDPI dwrite: Return render bounds if text not intersect to BitmapRenderTarget https://gitlab.winehq.org/wine/wine/-/merge_requests/3718

3 5

[PATCH 0/1] MR4851: kernelbase: Add naive SystemTimeToTzSpecificLocalTimeEx implementation
by Russell Greene (＠russelltg) 26 Nov '24

26 Nov '24

The cast there seems safe from looking at the struct definitions, and is also used elsewhere in the codebase (dlls/kernelbase/locale.c:5682). It's obviously not a full implementation, but works well enough for my usecase and maybe others as well. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4851

3 3

[PATCH v4 0/3] MR3547: Common Controls: Fix balloon tooltips
by Carl Bialorucki (＠cbialorucki) 25 Nov '24

25 Nov '24

Fixes balloon tooltips so that they can be drawn outside of the work area (required for system tray icons) and improves the shape of the tooltips so that they resemble their shape on Windows. -- v4: Diff reduce https://gitlab.winehq.org/wine/wine/-/merge_requests/3547

4 4

[PATCH 0/7] MR4947: winewayland.drv: part 12: Display mode change emulation
by Alexandros Frantzis (＠afrantzis) 23 Nov '24

23 Nov '24

This MR uses the existing compositor side surface scaling in the driver (through wp_viewporter, currently used for Hi-DPI scaling) to emulate display mode changes. This works wonderfully in coordination with fullscreen since the compositor is required non only to scale the surface, but also to position it properly and provide opaque surroundings (note: some compositors don't implement the last two features properly!). Since: 1. Wayland doesn't allow clients to change the actual display configuration, and 2. there is no queryable service that holds the display information in a consistent manner (à la xrandr), the MR uses the win32 device settings as the source of truth for the current display mode. We let win32u handle the display mode change in the default manner (i.e., just updating the registry settings), and provide access to the current mode when updating the display devices through a new `gdi_display_manager.get_adapter()` function. In order to be able to consistently (across all processes) associate an adapter device with its corresponding `wl_output` the MR introduces per-adapter driver data. Note for people trying this out: many modern games don't change the hardware display settings, but rather scale themselves in right way to achieve the visual effect of a mode change (similarly to how this MR works, but they do it on the application side). To exercise most of the functionality in this MR you need an application that actually uses the `ChangeDisplaySettings` win32 API. Thanks! -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4947

16 48