- wine-gitlab - winehq.org

[PATCH 0/1] MR4710: winedbg: Add wow option in info share usage.
by Bernhard Übelacker (＠bernhardu) 18 Dec '23

18 Dec '23

This patch just adds to the usage the "wow" keyword, which causes all modules to be listed instead of just the ones of the process executables architecture. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4710

3 4

[PATCH 0/2] MR4712: Speed-up and fix for dbghelp.SymLoadModule().
by eric pouech (＠epo) 18 Dec '23

18 Dec '23

Some games exhibit freeze in game play because they implement something like: - upon an event (exception...) - use toolhelp to get a snapshot of self loaded modules, - call SymLoadModule() on each module, - furthermore, they keep their dbghelp session active, and redo the process above when a new event occurs. This ends up with trying to reload at the very same base address each one of the already loaded modules. Native implements a fast exit path when asking to load a module at the exact same base address of an already loaded one: it simply bails out (without checking anything else). Builtin is way more slow (it resync:s ELF/Mach-o module list, load the new module before actually dropping at the end of the process). This can result in second of relay. This serie adds the tests for supporting above claim and fix it. Credit to Paul Gofman for triaging this behavior. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4712

2 2

[PATCH 0/2] MR527: vkd3d-shader: Implement I/O for shader model 2.
by Zebediah Figura (＠zfigura) 18 Dec '23

18 Dec '23

-- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/527

2 2

[PATCH 0/2] MR4711: Fix Toad for Oracle F3 find next function not working properly
by Zhiyi Zhang (＠zhiyi) 18 Dec '23

18 Dec '23

Fix Toad for Oracle F3 find next function not working properly because its WH_KEYBOARD hook gets called too many times. There is another case that could cause WH_CBT HCBT_CLICKSKIPPED hooks to get called recursively as the tests show. I will send patches for that after the code freeze. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4711

2 2

Re: [PATCH v8 0/6] MR3288: Draft: gdiplus: Clip polygons before drawing them - closed
by David Kahurani (＠kahurani) 17 Dec '23

17 Dec '23

This merge request was closed by David Kahurani. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3288

1 0

Re: [PATCH v8 0/6] MR3288: Draft: gdiplus: Clip polygons before drawing them
by David Kahurani (＠kahurani) 17 Dec '23

17 Dec '23

Superceded by !4206 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3288#note_56170

1 0

[PATCH v3 0/1] MR4306: rpcrt4/tests: Use CRT allocation functions.
by Alex Henrie (＠alexhenrie) 16 Dec '23

16 Dec '23

-- v3: rpcrt4/tests: Use CRT allocation functions. https://gitlab.winehq.org/wine/wine/-/merge_requests/4306

3 2

Re: [PATCH v8 0/6] MR3288: Draft: gdiplus: Clip polygons before drawing them
by Esme Povirk (＠madewokherd) 16 Dec '23

16 Dec '23

On Sat Dec 16 08:27:12 2023 +0000, David Kahurani wrote: > "I don't believe draw_poly is the right place for this. Either > optimizations should be in gdi32, or in SOFTWARE_GdipFillPath (which we > don't use now for drawing outlines because the gdi32 path is currently > more efficient, but we could if that changed)." > Looking at this again, it looks like we should try to re-implement > SOFTWARE_GdipFillPath to allow for drawing outlines. Maybe add a flag > for whether we need to outline only and when we need to fill it? We have a special case for drawing 1-pixel outlines. In other cases, the way to do that is by generating a path for the outline with GdipWidenPath and filling that. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3288#note_56161

1 0

[PATCH 0/1] MR4706: vulkan-1/tests: Enable feature in private data test.
by Georg Lehmann (＠DadSchoorse) 16 Dec '23

16 Dec '23

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

2 1

Re: [PATCH v8 0/6] MR3288: Draft: gdiplus: Clip polygons before drawing them
by David Kahurani (＠kahurani) 16 Dec '23

16 Dec '23

On Fri Dec 15 16:56:08 2023 +0000, Esme Povirk wrote: > My thinking is that we will eventually need to implement an equivalent > for `GdipGetRegionHrgn` that returns some raw data instead of an HRGN, > and more importantly optimizes generally for known bounding boxes (this > would include the Graphics bounding box as well as its clip region). See > https://gitlab.winehq.org/wine/wine/-/merge_requests/4206 for some of my > initial work on that. > If we do the translation outside of gdi32, we can do it by scanline and > treat the path as a set of independent line segments. We can then ignore > scanlines and line segments outside of our output range. I think > `create_polypolygon_region` in win32 does something similar, but sadly I > don't think there's a way to pass in a value for `clip_rect` from the outside. "I don't believe draw_poly is the right place for this. Either optimizations should be in gdi32, or in SOFTWARE_GdipFillPath (which we don't use now for drawing outlines because the gdi32 path is currently more efficient, but we could if that changed)." Looking at this again, it looks like we should try to re-implement SOFTWARE_GdipFillPath to allow for drawing outlines. Maybe add a flag for whether we need to outline only and when we need to fill it? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3288#note_56152

1 0

2025

2024

2023

2022

wine-gitlab