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).
--
v6: 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
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
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
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
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