Canvas co-ordinate rounding e.g. 118.0 -> 117.99999

Logged In: YES
user_id=15949
Originator: NO

Note that I see something similar in the tk test suite. For example:
canvRect.test

==== canvRect-9.1 ScaleRectOval procedure FAILED
==== Contents of test case:

.c delete withtag all
.c create rect 100 300 200 350 -tags x
.c scale x 50 100 2 4
.c coords x

---- Result was:
150.0 900.0 350.0 1099.9999999999998
---- Result should have been (exact matching):
150.0 900.0 350.0 1100.0
==== canvRect-9.1 FAILED

==== canvRect-10.1 TranslateRectOval procedure FAILED
==== Contents of test case:

.c delete withtag all
.c create rect 100 300 200 350 -tags x
.c move x 100 -10
.c coords x

---- Result was:
200.0 290.0 300.0 339.99999999999994
---- Result should have been (exact matching):
200.0 290.0 300.0 340.0
==== canvRect-10.1 FAILED

Logged In: YES
user_id=1043388
Originator: YES

Hmmmm , i've found the cause of this issue. This seems related to tcl_precision:
Tcl8.4 "tclvars" man-page:
tcl_precision
This variable controls the number of digits to generate when con-
verting floating-point values to strings. It defaults to 12.
tcl8.5:
tcl_precision
This variable controls the number of digits to generate when con-
verting floating-point values to strings. It defaults to 0.
Applications should not change this value; it is provided for com-
patibility with legacy code.

Well.. this is breaking my "legacy" canvas app, polypuzzle. "set tcl_precision
12" fixes my problem, but the doco explicitly says not to do this. Perhaps
some work needs still to be done here.... Could someone please let me know
what i should be doing ?

Logged In: YES
user_id=98900
Originator: NO

The basic problem is that canvas coordinates goes
through the "mm" object type leading to slight rounding
errors, and probably some shimmering. This becomes
visible in 8.5 with the new exact string reps of floats.
If Tk_CanvasGetCoordFromObj checked for double/int
objects, in the same manner as SetMMFromAny does, before
calling Tk_GetMMFromObj it would make things nicer
and probably faster.

Logged In: YES
user_id=98900
Originator: NO

Another alternative would be to make a double
version of Tk_GetPixelFromObj and use that in
canvas instead, skipping the mm object altogether.

Logged In: YES
user_id=1043388
Originator: YES

Under Wish 8.5.2 this seems better. Most of the time there's no problem... But under fedora 7 , ONLY AT 1154 screen resolution, it still happens. It's unusual that there shold still be a problem at this resolution only. !&^%$

Fully agreeing with Peter. As it turns out, GetDoublePixels is ready for the job.
I'd only want a green light from Jeff before submitting the patch.

In fact, GetDoublePixels is a pure-string thing from pre-obj times.
Instead, the attached patch defines a double version of Tk_GetPixelsFromObj as suggested by Peter.
Passes the test suite.
File Added: doublepixels.patch

This fixes some broken tests for me on WinXP using the 8.6 HEAD. Seems good.

Oops I spoke too soon.
Checking the canvas demo - the first one in the canvas section (1. The cavas item types) all the items are drawn up at the top left. They should be spread around the whole canvas.

Funny that the test suite failed to capture that !
Investigating...

OK, got it. I forgot to force the unit back to pixels (internal unit-shimmering). Sorry about that. Expect fix shortly.

Fixed patch. Refactored a bit to avoid duplication while staying at full speed.
File Added: doublepixels2.patch

Pat, can you review ?

Patch now extended to the only other client of the millimeter type, tkText.c
So now mmObjType is unused in the core. Cannot be deprecated though, because (1) there is a stub entry mentioning it, and (2) it is registered. But not using it at all is enough to make me happy.
File Added: doublepixels3.patch

Committed to HEAD. Would appreciate help for backports.

There are still some problems in the demos. The Canvas 5 (A ruler with adjustible tab stops) demo is wrong and Animation 3 (Pendulum swing) is failing to draw the phase space graph.

Fixed, and committed as revision 1.24 of tkObj.c
A stupid bug (uninited var in one condition).

backport for 8.5.6 ?

Done :)
No misbehavior detected, but I'd appreciate a review of the demos, because the test suite has a needle-haystack issue on my system.
Also, I see I committed late... feel free to bump the tag or not.