[PATCH v3 0/1] MR6662: win32u/zibdrv: Round get_arc_max_points() value to a multiple of 4.

[Aida Jonikienė (＠DodoGTA)]

This seems like a weird solution to me (so I'm not sure if the tests pass)

--
  v3: win32u/dibdrv: Round get_arc_max_points() value to a multiple of 4.

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

[PATCH v3 1/1] win32u/dibdrv: Round get_arc_max_points() value to a multiple of 4.

[Aida Jonikienė]

From: Aida Jonikienė

Fixes: 5924ab4c515 ("win32u: Implement drawing transformed round rectangles.")
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=57306
---
 dlls/win32u/dibdrv/graphics.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/dlls/win32u/dibdrv/graphics.c b/dlls/win32u/dibdrv/graphics.c
index 414737fa8ca..89876323197 100644
--- a/dlls/win32u/dibdrv/graphics.c
+++ b/dlls/win32u/dibdrv/graphics.c
@@ -367,12 +367,13 @@ static unsigned int get_arc_max_points( DC *dc, const RECT *rect )
         {rect->right, rect->bottom},
         {rect->right, rect->top}
     };
-    unsigned int width, height;
+    unsigned int width, height, points;

lp_to_dp( dc, pts, 4 );
     width = max( abs( pts[2].x - pts[0].x ), abs( pts[3].x - pts[1].x ));
     height = max( abs( pts[2].y - pts[0].y ), abs( pts[3].y - pts[1].y ));
-    return (width + height) * 3;
+    points = (width + height) * 3;
+    return (points + 3) & ~3;
 }

/* backend for arc functions; extra_lines is -1 for ArcTo, 0 for Arc, 1 for Chord, 2 for Pie */

[Aida Jonikienė (＠DodoGTA)]

On Sun Oct 13 17:00:55 2024 +0000, Aida Jonikienė wrote:
> changed this line in [version 3 of the diff](/wine/wine/-/merge_requests/6662/diffs?diff_id=137878&start_sha=cccf64244c56ac2e4b7c86fa9870fcb9374b8bd9#7e258e82f92bfdcc9880f65005d937fdba90d7da_376_376)

Done

[Huw Davies (＠huw)]

This looks like it's just working around the bug; it seems unlikely that the number really should be rounded up to the next multiple of four.

[Aida Jonikienė (＠DodoGTA)]

On Sun Oct 13 17:46:56 2024 +0000, Huw Davies wrote:
> This looks like it's just working around the bug; it seems unlikely that
> the number really should be rounded up to the next multiple of four.

The other solution I have is adding a `- 1` to the `top_points + count` argument on line 1561 (but I'm not sure if that's good either)

[Aida Jonikienė (＠DodoGTA)]

Once !6685 gets merged I'll close this MR (because it solves the same issue)

[PATCH v3 0/1] MR6662: win32u/zibdrv: Round get_arc_max_points() value to a multiple of 4. - closed

[Aida Jonikienė (＠DodoGTA)]

This merge request was closed by Aida Jonikienė.