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
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
--
v5: gdiplus: Implement font linking for gdiplus.
gdiplus/tests: Add interactive test for font linking.
mlang: Fix bug with codepage priority in GetStrCodePages.
mlang/tests: Test codepages priority bug in GetStrCodepages.
mlang: Implement GetGlobalFontLinkObject.
mlang/tests: Test for GetGlobalFontLinkObject.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4082
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=55967
Fixes a regression introduced by commit
efd03f40e6e315d89cd1d09c48180aae82033f9f.
The app reads syscall thunk for NtQueryInformationProcess() from ntdll file and just calls that from some memory location. That worked before the referenced commit because without performing relocations that was jumping to wine_syscall in the loaded ntdll.dll. Now when the actual ntdll load address is different that jumps to the same address which is now non sensual.
The existing tests show that in general 32-bit syscall thunks need relocation. The same trick with some other Nt functions I tried doesn't work on Windows, but turns out NtQueryInformationProcess is special (the included test replicates that). The form of syscall thunk I used in the patch corresponds to what was in Wine-Staging before the upsream implementation of syscall thunks (that is, call to NtCurrentTeb()->WOW32Reserved).
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4705
--
v3: vkd3d-shader/hlsl: Allow non-numeric types in the ternary operator.
vkd3d-shader/hlsl: Separate an add_ternary() helper.
tests: Add many more tests for ternary expressions.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/463