From: Jim I. <ji...@ap...> - 2005-03-14 18:24:59
|
I added this to the bug: I don't think this is relevant to this bug. I don't see it on the current TOT on 10.3 with the example cited. Note, the code is not calling "update" just "update idletasks". You can't call Tcl_ServiceAll because the Aqua code is using the Native Control to move the mouse around, and if you steal mouse events off the queue out from under the control, it doesn't move properly. But you can replace the call to "update idletasks" with a call to TclServiceIdle(). That seems to work just fine in my quick tests. The only difference between "update idletasks" and calling TclServiceIdle directly is that "update idletasks" calls XSync. This is redundant, because fetching the next event also flushes the drawing, and syncing with the server is a cross-process call on Mac OS X so it is more expensive than it was in the Classic MacOS. I think I will switch TOT to calling TclServiceIdle, since it seems to make the scrolling a little faster. But I don't think it has any relevance to this bug. To switch to just calling TclServiceIdle, try the following patch, I think this is marginally faster: Index: tkMacOSXScrlbr.c =================================================================== RCS file: /cvsroot/tktoolkit/tk/macosx/tkMacOSXScrlbr.c,v retrieving revision 1.9 diff -p -p -r1.9 tkMacOSXScrlbr.c *** tkMacOSXScrlbr.c 16 Feb 2004 00:19:42 -0000 1.9 --- tkMacOSXScrlbr.c 14 Mar 2005 18:19:21 -0000 *************** *** 16,21 **** --- 16,22 ---- #include "tkScrollbar.h" #include "tkMacOSXInt.h" + #include "tclInt.h" #include <Carbon/Carbon.h> *************** ThumbActionProc() *** 673,678 **** --- 674,691 ---- interp = scrollPtr->interp; Tcl_Preserve((ClientData) interp); Tcl_GlobalEval(interp, cmdString.string); + { + TkDisplay *dispPtr; + TclServiceIdle(); + #if 0 + for (dispPtr = TkGetDisplayList(); dispPtr != NULL; + dispPtr = dispPtr->nextPtr) { + XSync(dispPtr->display, False); + } + #endif + + } + #if 0 Tcl_Release((ClientData) interp); Tcl_DStringSetLength(&cmdString, 0); Tcl_DStringAppend(&cmdString, "update idletasks", *************** ThumbActionProc() *** 680,685 **** --- 693,699 ---- Tcl_Preserve((ClientData) interp); Tcl_GlobalEval(interp, cmdString.string); Tcl_Release((ClientData) interp); + #endif } } while ((err == noErr) && trackingResult != kMouseTrackingMouseReleased); By either 10.2 or maybe 10.3 there were API's to completely draw the track and the thumb, etc. for the Aqua scrollbar independently of the scrollbar callbacks. So it would also be possible to remove the TrackMouseLocationWithOptions stuff altogether, and just let Tk handle the events the way it does for the Unix code, and then draw the controls directly. This is probably the best way to go, making the Mac code more like the Unix version. Jim On Mar 14, 2005, at 4:55 AM, Vince Darley wrote: > A recent Tk bug report (crash): > > https://sourceforge.net/tracker/? > func=detail&atid=112997&aid=1143776&group_id=12997 > > seems to be triggered on TkAqua because of a direct call to 'update > idletasks' in the scrollbar code. Comparing this with the other > platforms, I see that they use a Tcl_ServiceAll() call, and don't > have any > need to call 'update'. This approach seems more robust given the > unknown > side-effects of the update command. > > Is there any reason TkAqua can't be changed to use an approach that is > closer to the other platforms? > > cheers, > > -- Vince > > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real > users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Tcl-mac mailing list > Tc...@li... > https://lists.sourceforge.net/lists/listinfo/tcl-mac |