Tk Source Code

Merged revised version:

• 8.6: [7a2bfd86] (with type bool replaced by type int)
• 9.0: [812237e0]
• 9.1: [6f1ecbab]

Thanks Christopher and eternal Francois for the fix ! Harald

I have verified the widget demo issue for ovals, which is critical. Ovals are drawn highly obscured. The comparison picture is attachement [widget_demo_canvas_items_ovals_patch-artefact_no-patch.png].

I can say, that the oval artefacts are gone with the patch by Christopher. Great work, I appreciate !

So I would be in favor to merge the branch now. If there is no objection, I will do so next Monday.

Thanks for all, Harald

It would be nice if this fix appears in Tk 9.0.3. Release cycle will start soon .....

Please have a look at [a89a807d], which is another attempted fix for both this ticket and the oval item regression. I do not mean to take credit for it though, as I have peeked at the source for the actual X11 server arc fill routines: https://github.com/XQuartz/xorg-server/blob/0ea9b59/mi/mifillarc.c#L678. These clamp the extent to ±360 degrees, which makes sense since it is historically constrained to the signed 16-bit range which itself is not much larger than [-64*360,64*360].

Thanks. It is better to know bad knews. Backed out by:

• main: [0ef7d5d7]
• conre-9-0-branch: [0200b4c1]
• core-8-6-branch: [9a639671]

Thanks, Harald

Unfortunately the change for this issue has introduced a regression where oval items no longer draw properly (see e.g. canvas items widget demo) and might need to be backed out for now. Sorry for the inconvenience.

Fix merged to all branches:

• core-8-6-branch: [f931dc9d]
• core-9-0-branch: [4a7631db]
• main: [dfda5dd3]

Thanks for Christopher and Francois for the bugfix, highly appreciated. All but one bugfix for Tk in upcoming Tk 8.6 release are from Christopher. Thanks for the action !

Closing.

Take care, Harald

I have made a local test. The test does not fail for me. So, it is probably a timeout issue.

I will merge now.

Thanks for all, Harald

There is one canvas test with images failing:

https://github.com/tcltk/tk/actions/runs/18675528966/job/53244610140#step:9:310

I will try to run manually.

Thanks, Harald

Ok. CI scheduled. Will merge when result is positive.
I don't think there is any issue which might be detected by CI but anyway.

Thanks,
Harald

Christopher, looks good to me, thanks.

Test it, works great.

For me, it may be merged to main, core-9-0 and core-8-6.

Shall I do that?

Thanks, Harald

The recipe does not work. You need a tcl9.1, as this is tk9.1 now. Best would be to use a tcl from the main branch. The naming of the folders should be tcl9.1 and tk9.1. This allows to avoid the specification of TCLDIR=c:\test\... when building tk. But it does not hurt.

Sorry, Harald

One error:

cd c:\test\tk9.0.2\tk -> cd c:\test\tk9.0.2\win

@ drh:

• Create a build folder. Example: c:\test
• Take the tcl 9.0.2 distribution and expand it to c:\test\tcl9.0.2
• Login as anonymous on core.tcl-lang.org/tk
• Download the zip of the tk branch here: https://core.tcl-lang.org/tk/info/06a80feb6edd0aa6 (button "zip archive")
• expand it beside in the folder c:\test to get folder c:\test\tk-06a80feb
• rename folder "tk-06a80feb" to tk9.0.2
• start a visual studio command prompt
• cd c:\test\tcl9.0.2\win
• nmake -f Makefile.vc
• nmake -f Makefile.vc install INSTALLDIR=c:\test\tcl902
• cd c:\test\tk9.0.2\tk
• nmake -f Makefile.vc
• nmake -f Makefile.vc install INSTALLDIR=c:\test\tcl902
• try the wish in c:\test\tcl902\bin

Good luck, Harald

Hi Harald,

> @dhr, are you able to test and confirm, that the patch is effective for you?

I would be happy to test it and confirm, but I don't know how to obtain the patched source/branch, and I don't know how to build Tcl/Tk from source on windows.

If there is a guide somewhere that explains what to do, let me know and I'll look into building and testing it, otherwise it's probably not worth your time/effort to teach me how to build Tcl/Tk on windows. Sorry for the trouble.

Thanks a lot Christopher and Harald for the work in investigating this issue.
Regards,
dhr

For testing the near-360 degree behavior, I used the reporter's animated example with -extent 359.8. The animation should show a complete or almost-complete filled circle and not "flicker".

François' approach is closer to the desired behavior, where arcs with an extent near 0 degrees still draw something (a point or line), rather than draw nothing as my approach does. Although his approach has the same issue as my first approach where an extent just under 360 degrees may get treated as 0 degrees and not draw as expected, I think that is easy to fix. So for now I would propose François' approach combined with an adjustment to handle near-360 degree arcs properly; see [06a80feb].

Regarding the other issues in [1081603], I do not know whether it is worth trying to get the arc drawing on Windows to match X11 exactly. Maybe such microscopic differences should be accepted as a limitation of the Win32 Tk port or the GDI functions it relies on.

I meant to check whether this issue is a duplicate, particularly given how long it has existed; apologies for not doing so earlier.

This appears to be the same issue described in the comment dated 2007-09-26 on [1081603], and for which François proposed a fix 8 years ago in [ed8e17cc]. I would want to look at his approach before proceeding.

Christopher, thanks, great, I appreciate !

I would love some additional source code commenting, why we need this flag. I can do that, if you like.

Is there an example to test the "rounded 360°" case ?

Perhaps, test wizard Eric may comment on the test possibility. Sad, thant magic Francois is not here any more, we miss his detailed work.

@dhr, are you able to test and confirm, that the patch is effective for you?

I am in favor (as TCT member) to merge to main, core-9-branch and core-8-6-branch. IMHO, the patch is an improvement, what is great. If Christover is also in favor, it may be merged.

Thanks for all, Harald

Harald, thanks for the review and creating the branch. Maybe an interactive test is possible for this issue, although I am not familiar with those.

As documented, the canvas arc items treat an extent of 360 degrees or more as the extent modulo 360 degrees, so it is not possible to specify 360 degrees exactly. However it is still possible to specify an amount like 359.8 degrees which may get rounded to 360 degrees by DrawOrFillArc(), so I have pushed a revised fix [32db5e81] which accounts for that.

Christopher, thanks for the fix. It is now in commit [2c3275d0] starting branch [6051a9fc-win-arc-small].

For me, it is effective. Now, only a line is drawn for both examples (MS-Win 11 64bit, MS-VS2022 64 bit).

I have two questions:

• may a test case be possible?
• what happens, if I want to fill 360°? Does it still work? Don't we need an indication, if the two numbers got equal due to rounding or by intention?

Thanks for all, Harald

A note for the reporter: consider using [tk windowingsystem] to check for X11/Win32/Aqua rather than $tcl_platform(os).

In DrawOrFillArc() (tkWinDraw.c), input angles are converted to radials. After rounding, it is possible for these radials to be identical, i.e. xstart == xend and ystart == yend. The problem is that passing identical radials to the Win32 GDI functions Arc(), Chord(), and Pie() causes them to draw 360 degrees, rather than 0 degrees as Tk seems to expect. Note: only the rectangular portion within the bounding box of an arc item is visible, and not necessarily all of the 360 degrees of drawing.

A naïve solution might be something like this, although I am not certain it is correct for XFillArc() usage other than canvas arc items:

--- win/tkWinDraw.c
+++ win/tkWinDraw.c
@@ -1261,7 +1261,9 @@
 
     pen = SetUpGraphicsPort(gc);
     oldPen = SelectObject(dc, pen);
-    if (!fill) {
+    if ((xstart == xend) && (ystart == yend)) {
+	/* Do nothing. See bug [6051a9fc] */
+    } else if (!fill) {
 	/*
 	 * Note that this call will leave a gap of one pixel at the end of the
 	 * arc for thin arcs. We can't use ArcTo because it's only supported

Thanks for the report. I can confirm, that the bug is in Tk 8.6.16 and Tk 9.0.2.

Attached is a screenshot of the first example, as the 2nd example is animated and hard to make a screen shot.

For me, it is also clear, that we need an antialiased version, as this looks outdated.

I also tested with undroidwish. It does not have the bug (see attached).

For those who want to understand the issue, please compare the undrowish and the windows screenshot.

package require Tk

canvas .c -width 200 -height 200 -background black
pack .c -expand 1 -fill both
pack [label .l -anchor w] -fill x
pack [label .l2 -text "Tk $tk_version"] -fill x

set itm [.c create arc 2 2 199 199 \
 -outline pink \
 -fill red \
 -extent 0.2]

wm title . "Testing: $tcl_platform(os)"

set start 0.1

proc animate {} {
 global start itm
 set start [expr {$start + 0.171671}]
 .c itemconfigure $itm -start $start
 .l configure -text $start
 after 17 animate
}

animate