August 2024 - Wine-GitLab - list.winehq.org

Re: [PATCH v2 0/16] MR6323: Draft: winewayland: Support GL/VK rendering in child windows (alt).
by Alexandros Frantzis (＠afrantzis) Aug. 21, 2024

Aug. 21, 2024

Thanks for the proposal! I have made [a couple of additional changes](https://gitlab.winehq.org/afrantzis/wine/-/commits/wip/wayland-chi… to this branch, to improve the behavior in some nested and visibility scenarios. The locking simplification changes look very nice, and perhaps it would be good to land them independently of whatever child accel. rendering design we go with. Concerning the child. accel design proposed, I am not sure if I find it less complex, but rather differently complex. !6107 centralizes the complexity in the `wayland_surface` update logic, but then other parts of the code can just use it without caring about most of the details. This MR has simpler parts, but then spreads out the complexity, since other parts need to care about `wayland_surface` vs `wayland_client_surface` etc. I am sure this perception about complexity is affected by my mind being used to the other design, though, and there are certainly benefits to this MR (e.g., avoiding an intermediate `wl_surface` when doing child accel. rendering). However, note that a big part of the design and complexity of !6107 is due to wanting to provide a more general mechanism for using subsurfaces for any kind of window. This makes is very easy to support popup positioning over !6107, doing something like https://gitlab.winehq.org/afrantzis/wine/-/commit/63baaec4379fb3222a08aae01…. This MR doesn't deal with that (which is fine), but then it's not clear to me how an approach based on this design would evolve and how complex it would become to support the popup positioning scenarios we want (and whether it would then be worth it over !6107). I think this may need a bit more exploration to get a more complete picture (or perhaps you already have a good idea of how this would look like?). -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6323#note_79403

1 0

[PATCH 0/2] MR6326: msi: Fix row index calculation when stringtable contains empty slots.
by Piotr Caban (＠piotr) Aug. 21, 2024

Aug. 21, 2024

Native msi deletes strings if no longer used. It's possible to create string table with empty slots this way. In such case we may add new row at incorrect index causing the table to be not sorted by primary key. This affects 3ds Max 2024 installers that contain such string table. I don't see how to add a test case for that without adding precreated MSI file. In order to create such file in tests we will need to implement strings refcounting (that is currently mostly missing). It looks like a big task that will likely introduce regressions. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6326

3 5

[PATCH 0/4] MR6332: win32u: Move visible rect computation out of the drivers.
by Rémi Bernon Aug. 21, 2024

Aug. 21, 2024

Using a new GetWindowStyleMasks driver entry to get the style masks to be used to mask out non-client decorations which are hidden by the host decorations. This is done after WindowPosChanging, as winex11 needs to update its managed flag before computing the visible rect, this means that the visible rect might change between WindowPosChanging and WindowPosChanged. It should hopefully be fine. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6332

1 5

[PATCH v2 0/8] MR6331: win32u: Implement DPI scaled window surface.
by Rémi Bernon Aug. 21, 2024

Aug. 21, 2024

Right now this should not do anything because all windows are per-monitor DPI aware. When this is changed this will automatically fall back to window surface scaling through `NtGdiStretchBlt` in win32u. This has the disadvantage that `NtGdiStretchBlt` is doing an absolutely terrible job at upscaling. This then adds a way for drivers to opt-in and do their own surface scaling before falling back to win32u. Alternatively and perhaps better, we could pull libcairo and use it to scale the surface contents with high quality filtering instead of using GDI. -- v2: win32u: Implement DPI scaled window surface. win32u: Move window_surface creation helper to dce.c. win32u: Map window rects DPI before calling into the drivers. win32u: Map window region DPI before calling into the drivers. winex11: Use the driver rects to convert from host visible to window rect. winex11: Keep a window_rects struct in the driver window data. win32u: Move visible rect computation out of the drivers. win32u: Keep SetIMECompositionWindowPos with other IME entries. https://gitlab.winehq.org/wine/wine/-/merge_requests/6331

1 10

[PATCH 0/4] MR6330: H264enc
by Ziqing Hui (＠zhui) Aug. 21, 2024

Aug. 21, 2024

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

4 7

[PATCH 0/4] MR6310: win32u: Move managed flag and visible rect computation out of the drivers.
by Rémi Bernon Aug. 21, 2024

Aug. 21, 2024

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

3 11

[PATCH 0/8] MR6331: win32u: Implement DPI scaled window surface.
by Rémi Bernon Aug. 21, 2024

Aug. 21, 2024

Right now this should not do anything because all windows are per-monitor DPI aware. When this is changed this will automatically fall back to window surface scaling through `NtGdiStretchBlt` in win32u. This has the disadvantage that `NtGdiStretchBlt` is doing an absolutely terrible job at upscaling. This then adds a way for drivers to opt-in and do their own surface scaling before falling back to win32u. Alternatively and perhaps better, we could pull libcairo and use it to scale the surface contents with high quality filtering instead of using GDI. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6331

1 8

[PATCH 0/1] MR6100: msxml3: Ensure node name is null terminated.
by Daniel Lehman (＠dlehman25) Aug. 21, 2024

Aug. 21, 2024

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

5 9

[PATCH 0/1] MR6329: snmpapi: Remove unnecessary call to strlen from SnmpUtilIdsToA.
by Alex Henrie (＠alexhenrie) Aug. 21, 2024

Aug. 21, 2024

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

2 1

[PATCH 0/2] MR5994: Draft: winewayland.drv: Make owned windows into xdg_popups
by Anna Figueiredo Gomes (＠navi) Aug. 20, 2024

Aug. 20, 2024

in tiling compositors, or those with decorations always on, having popups (like menu items or on-hover tooltips) be set as toplevels causes them to become unusable. Instead, if a HWND is owned by another window that has a wayland surface, create the surface as a xdg_popup of the owner. since i couldn't find any info on this issue aside from https://bugs.winehq.org/show_bug.cgi?id=56278, i decided to try and fix it. those patches are a WIP, currently it manages fine running tools like notepad.exe and notepad++, but gimp and winecfg still don't work. some tests, namely tooltip.c in comctl32 are failing, although i can reproduce the failure on the master branch, will look into it. Signed-off-by: Anna (navi) Figueiredo Gomes <navi(a)vlhl.dev> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5994

4 7