Tk Source Code

View Ticket
Login
Ticket UUID: ad9a023e45b33d7c02514c3bdd1a85db55ee193c
Title: Applying canvas move command to objects leaves trails (Again)
Type: Bug Version: 8.6.11
Submitter: anonymous Created on: 2021-09-09 17:36:47
Subsystem: 05. Canvas Items Assigned To: nobody
Priority: 5 Medium Severity: Important
Status: Open Last Modified: 2026-10-08 16:07:48
Resolution: None Closed By: nobody
    Closed on:
Description:
I know this was an old fixed bug, but I experienced again today.

I'm with TclTk 8.6.11 on Windows
and I noticed this astonishing behavior:
 when I move a canvas item by few pixel, some items (rectangle!) leav trails.

As you can see from this picture 
  https://wiki.tcl-lang.org/page/Canvas+Trails
some 3 (identical) rectangles on 4 when moved leave some dirty pixel under the old position.

Maybe the picture and the script below can help.

As far as I know, this bad behaviour happens only if the items have some non-integer coordinates
BUT it does not occur if the item has all-positive coords (BOX in quadrant Q1 ha no trails !)

# ----------------------------------------------------------------------

canvas .c -bg yellow
pack .c -expand 1 -fill both

 # draw XY axis
.c create line -1000 0 1000 0
.c create line 0 -1000 0 1000

 # move the axis origin to the center of the window (well .. near the center)
.c scan mark 0 0
.c scan dragto 300 300 1

 # draw 4 rect, each in one XY quadrant

.c create rectangle 100 100 200 200 -tag "BOX BQ1"
.c create text 20 20 -text "Q1"

.c create rectangle 100 -200 200 -100 -tag "BOX BQ2"
.c create text 20 -20 -text "Q2"

.c create rectangle -200 -200 -100 -100 -tag "BOX BQ3"
.c create text -20 -20 -text "Q3"

.c create rectangle -200 200 -100 100 -tag "BOX BQ4"
.c create text -20 20 -text "Q4"

# touch the 4 BOX coords so that they are not integer ...
.c move BOX 0.5 0.5

# ---------------------
# now STOP HERE and type the following commands 
# ONE BY ONE from the console
# (the "update" command is just for forcing a redisplay after each "move")
# ---------------------

.c move "BQ1" 2 -2  ; update
.c move "BQ1" 2 -2  ; update
  
.c move "BQ2" 2 -2  ; update
.c move "BQ2" 2 -2  ; update


.c move "BQ3" 2 -2 ; update
.c move "BQ3" 2 -2 ; update

.c move "BQ4" 2 -2 ; update
.c move "BQ4" 2 -2 ; update
User Comments: serhiy.storchaka added on 2026-10-08 16:07:48:

The test was wrong, not the fix: on Windows the bounding box of an item without outline is one pixel larger (bloat = 1 in ComputeRectOvalBbox()), so its corners are not drawn. Branch canvas-test-win-bbox checks the filled pixels directly and that the bounding box contains them, and runs the test on all platforms again. It passes on X11 and Windows 11 with the fix and fails on both without it.


jan.nijtmans added on 2026-10-08 15:47:03:

On Windows, I'm seeing:

==== canvas-24.2 an item with negative coordinates ending in .5 is drawn inside its bounding box - bug ad9a023e45 FAILED
==== Contents of test case:
    .c create rectangle -10.5 -10.5 -5.5 -5.5 -fill black -outline {}
    update
    # The canvas coordinate (x, y) is at the pixel (x + 30, y + 30) of the
    # window.  The corner pixels of the bounding box must be drawn, and the
    # pixels just outside it must not.
    lassign [.c bbox 1] x1 y1 x2 y2
    set res [list $x1 $y1 $x2 $y2]
    foreach {x y} [list $x1 $y1 [expr {$x2 - 1}] [expr {$y2 - 1}]  [expr {$x1 - 1}] [expr {$y1 - 1}] $x2 $y2] {
	lappend res [testpixel .c [expr {$x + 30}] [expr {$y + 30}]]
    }
    set res
---- Result was:
-12 -12 -5 -5 #ffffff #ffffff #ffffff #ffffff
---- Result should have been (exact matching):
-11 -11 -6 -6 #000000 #000000 #ffffff #ffffff
==== canvas-24.2 FAILED

For now, I made this test unix-only, but it would be nice to make this testcase work on Windows as well


serhiy.storchaka added on 2026-09-18 21:38:50:

Reproduced on X11 with rectangles and ovals at negative coordinates. The coordinates were rounded differently for drawing and for the bounding box, so an item with a negative coordinate with fraction .5 was drawn one pixel outside its bounding box. Fix in branch [92b3bc6526].