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
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
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
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