September 2024 - Wine-GitLab

Re: [PATCH v4 0/9] MR6480: mfsrcsnk: Implement I/O for the FFmpeg backend.
by Emil Velikov (＠xexaxo) Sept. 13, 2024

Sept. 13, 2024

Emil Velikov (@xexaxo) commented about dlls/winedmo/main.c: > { > struct stream_context *context; > > - if (!(context = malloc( sizeof(*context) ))) return NULL; > + if (!(context = malloc( 0x10000 ))) return NULL; Any chance we get an inline comment saying how `0x10000` was chosen? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6480#note_82137

1 0

Re: [PATCH v4 0/9] MR6480: mfsrcsnk: Implement I/O for the FFmpeg backend.
by Emil Velikov (＠xexaxo) Sept. 13, 2024

Sept. 13, 2024

Emil Velikov (@xexaxo) commented about dlls/winedmo/unixlib.h: > > struct demuxer_create_params > { > + struct stream_context *context; > struct winedmo_demuxer demuxer; Out of curiosity: is the `stream_context` expected to have different life-time than `winedmo_demuxer`? Alternatively it seems cleaner to me to have the `stream_context` pointer within the `winedmo_demuxer` itself removing the rather uncommon read-back pointer from the destructor. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6480#note_82136

1 0

[PATCH 0/1] MR6493: gdiplus: Fix assignment of result in GdipCloneBrush.
by Esme Povirk (＠madewokherd) Sept. 13, 2024

Sept. 13, 2024

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=57181 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6493

2 1

[PATCH 0/2] MR6492: d2d1: Implement drawing of ID2D1GeometryGroup
by Philipp Knechtges (＠d1saster) Sept. 13, 2024

Sept. 13, 2024

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) Sept. 13, 2024

Sept. 13, 2024

-- 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 Sept. 13, 2024

Sept. 13, 2024

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

3 14

[PATCH v5 0/5] MR6375: mshtml: Don't process tasks recursively.
by Gabriel Ivăncescu Sept. 13, 2024

Sept. 13, 2024

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

2 11

Re: [PATCH v15 0/1] MR6453: emfdc: avoid memory leaks in get_bitmap_info - approved
by Jacek Caban (＠jacek) Sept. 13, 2024

Sept. 13, 2024

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

1 0

Re: [PATCH v2 0/8] MR6430: misc: Register DMO classes from their native DLLs.
by Rémi Bernon Sept. 13, 2024

Sept. 13, 2024

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) Sept. 13, 2024

Sept. 13, 2024

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