September 2024 - wine-gitlab

[PATCH 0/2] MR6492: d2d1: Implement drawing of ID2D1GeometryGroup
by Philipp Knechtges (＠d1saster) 13 Sep '24

13 Sep '24

The functionality to draw ID2D1GeometryGroup is currently missing. Nothing is drawn. This causes the blank pages in the bug below. The merge request contains both a test and a potential fix that at least partially alleviates the problems. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=51139 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6492

3 3

[PATCH 0/1] MR6490: winsock: Avoid short writes on nonblocking sockets.
by Paul Gofman (＠gofman) 13 Sep '24

13 Sep '24

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

5 8

[PATCH v4 0/8] MR6467: winex11: Implement vulkan DPI scaling and child window rendering.
by Rémi Bernon (＠rbernon) 13 Sep '24

13 Sep '24

This does the same as https://gitlab.winehq.org/wine/wine/-/merge_requests/6398 but for Vulkan. It also implements vulkan child window rendering pretty much for free and supersedes https://gitlab.winehq.org/wine/wine/-/merge_requests/5573. It is not completely optimal and there as missed opportunities to keep child windows on screen when no DPI scaling and no cropping is needed, but it would require to be smarter and have knowledge about the window clipping region, which will probably better be done in win32u. This is exactly the same for OpenGL, and it will probably be solved together. -- v4: winex11: Implement vulkan DPI scaling and child window rendering. winex11: Move offscreen client window helpers to init.c. winex11: Only update the client window position in sync_client_position. winex11: Update the GL client window size when it is presented. winex11: Update the vulkan surface size when it is presented. winex11: Use a dedicated structure for vulkan surface private data. win32u: Pass vulkan driver private data to vulkan_surface_presented. winevulkan: Use client rect in window DPI instead of monitor DPI. https://gitlab.winehq.org/wine/wine/-/merge_requests/6467

4 14

[PATCH v5 0/5] MR6375: mshtml: Don't process tasks recursively.
by Gabriel Ivăncescu (＠insn) 13 Sep '24

13 Sep '24

I kept the first patch (`Remember if timer was blocked.`) to avoid SetTimer on timers that weren't killed, mostly because it would apply on every task (which is likely to execute way faster than the ms granularity), not sure if it would skew the timer in such case. The other patches are split, with tests now showing why they're needed. Some places where wine-gecko callbacks into us and in which we call into external code need to be treated the same as a recursive task since it can end up in a message loop. I haven't supplied all of them from the previous MR, mostly because I didn't find a way to test those (e.g. show context menu, and the gecko async navigation). -- v5: mshtml: Don't process tasks recursively from Gecko events. mshtml: Don't process tasks recursively from script runners. mshtml: Don't process tasks recursively. mshtml: Remember if timer was blocked. mshtml: Don't cast to int to bound the timer. https://gitlab.winehq.org/wine/wine/-/merge_requests/6375

3 11

Re: [PATCH v15 0/1] MR6453: emfdc: avoid memory leaks in get_bitmap_info - approved
by Jacek Caban (＠jacek) 13 Sep '24

13 Sep '24

This merge request was approved by Jacek Caban. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6453

1 0

[PATCH 0/4] MR6462: winemac: Use win32u for move/resize window SysCommand.
by Rémi Bernon (＠rbernon) 13 Sep '24

13 Sep '24

It's not completely clear what exactly it was doing differently from win32u, but keeping the captions within the work area is probably fine for win32u, and de-duplicating this code is probably a good thing and makes later changes for DPI-based virtual display settings easier. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6462

2 5

Re: [PATCH v2 0/8] MR6430: misc: Register DMO classes from their native DLLs.
by Rémi Bernon (＠rbernon) 13 Sep '24

13 Sep '24

On Fri Sep 13 08:31:24 2024 +0000, Ziqing Hui wrote: > Sounds like we will have 2 backend: winegstreamer and winedmo. For the > mftransforms front ends, like h264 encoder transform, h264 decoder > transform, wmv decoder dmo, will we have 2 seperate front ends? Yes, duplicating the frontend code seems like the easiest thing to do. The video encoder source could live in mfh264enc, and if we need more video encoder modules, they could share its source with PARENTSRC. Note that I haven't explored the encoding path very much yet, so we can probably not worry about it and just keep using GStreamer only for it for now. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6430#note_82104

1 0

Re: [PATCH v2 0/8] MR6430: misc: Register DMO classes from their native DLLs.
by Ziqing Hui (＠zhui) 13 Sep '24

13 Sep '24

On Fri Sep 13 08:29:22 2024 +0000, Ziqing Hui wrote: > Which folder will the video_encoder.c be placed? We are putting the PE > frontend implementation of video encoder in winegstreamer now. Will we > have a duplicate video_decoder.c in winedmo folder? Sounds like we will have 2 backend: winegstreamer and winedmo. For the mftransforms front ends, like h264 encoder transform, h264 decoder transform, wmv decoder dmo, will we have 2 seperate front ends? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6430#note_82103

1 0

Re: [PATCH v2 0/8] MR6430: misc: Register DMO classes from their native DLLs.
by Ziqing Hui (＠zhui) 13 Sep '24

13 Sep '24

On Fri Sep 13 08:05:59 2024 +0000, Rémi Bernon wrote: > I'm thinking to implement these with winedmo, while keeping the > redirection to the winegstreamer backend as default. Which folder will the video_encoder.c be placed? We are putting the PE frontend implementation of video encoder in winegstreamer now. Will we have a duplicate video_decoder.c in winedmo folder? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6430#note_82102

1 0

[PATCH 0/1] MR5787: winevulkan: Use an internal NtUser call to retrieve a GPU LUID.
by Rémi Bernon (＠rbernon) 13 Sep '24

13 Sep '24

Avoid taking the display_device_init mutex outside of win32u. Similar to https://gitlab.winehq.org/wine/wine/-/merge_requests/5786, although this one doesn't cause any problems as far as I know. Still makes things simpler. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5787

3 6

2025

2024

2023

2022

wine-gitlab September 2024