From: SourceForge.net <no...@so...> - 2008-11-24 22:50:48
|
Bugs item #1813597, was opened at 2007-10-15 07:28 Message generated for change (Comment added) made by patthoyts You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=112997&aid=1813597&group_id=12997 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: 04. Canvas Basics Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Steven (stevenaaus) Assigned to: Jeffrey Hobbs (hobbs) Summary: Canvas co-ordinate rounding e.g. 118.0 -> 117.99999 Initial Comment: Hmmmm... In the latest beta (8.5b1) canvas co-ordinate rounding has changed, (and is breaking my polypuzzle program). This wasn't the case in 8.5a[5|6]. I know this is a weak point of tcl... but perhaps as it is , lots of apps will break ? Below is a simple line created on a canvas in wish8.4 and then wish8.5b1. I then retrieve the coords.. Notice that in wish8.5 the 410.99999999999994 -> 410.9999999999999 , but *worse*, the 118.0 -> 117.99999999999999 Hmmm.. This last one is nasty. The rounding behaviour in 8.4 was very well behaved, and *never* gave me horrible point nines recurring. Anyway, thank-you for your time. Steven. Linux 2.6.23 #1 PREEMPT Fri Oct 12 19:07:53 UTC 2007 i686 i386 GNU/Linux, xorg-x11-6.8.2-31, glibc-2.3.5-10, Fedora 4 ---------------------------------------------------------------- #wish8.4 -------- % canvas .c .c % .c creat line 0 0 410.99999999999994 118.0 1 % .c coords 1 0.0 0.0 411.0 118.0 ---------------------------------------------------------------- #wish8.5b1 -------- % canvas .c .c % .c creat line 0 0 410.99999999999994 118.0 1 % .c coords 1 0.0 0.0 410.9999999999999 117.99999999999999 ---------------------------------------------------------------- ---------------------------------------------------------------------- Comment By: Pat Thoyts (patthoyts) Date: 2008-11-24 22:50 Message: This fixes some broken tests for me on WinXP using the 8.6 HEAD. Seems good. ---------------------------------------------------------------------- Comment By: Alexandre Ferrieux (ferrieux) Date: 2008-11-24 01:16 Message: 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 ---------------------------------------------------------------------- Comment By: Alexandre Ferrieux (ferrieux) Date: 2008-11-08 17:29 Message: 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. ---------------------------------------------------------------------- Comment By: Steven (stevenaaus) Date: 2008-05-17 02:01 Message: 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. !&^%$ ---------------------------------------------------------------------- Comment By: Peter Spjuth (pspjuth) Date: 2007-10-17 12:45 Message: 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. ---------------------------------------------------------------------- Comment By: Peter Spjuth (pspjuth) Date: 2007-10-17 11:47 Message: 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. ---------------------------------------------------------------------- Comment By: Steven (stevenaaus) Date: 2007-10-17 06:46 Message: 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 ? ---------------------------------------------------------------------- Comment By: Larry W. Virden (lvirden) Date: 2007-10-16 14:49 Message: 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 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=112997&aid=1813597&group_id=12997 |