ASPN ActiveState Programmer Network
ActiveState
/ Home / Perl / PHP / Python / Tcl / XSLT /
/ Safari / My ASPN /
Cookbooks | Documentation | Mailing Lists | Modules | News Feeds | Products | User Groups


Recent Messages
List Archives
About the List
List Leaders
Subscription Options

View Subscriptions
Help

View by Topic
ActiveState
.NET Framework
Open Source
Perl
PHP
Python
Tcl
Web Services
XML & XSLT

View by Category
Database
General
SOAP
System Administration
Tools
User Interfaces
Web Programming
XML Programming


MyASPN >> Mail Archive >> tcl-core
tcl-core
Re: [TCLCORE] [MACTCL] Woeful canvas performance 8.5.2
by Daniel A. Steffen other posts by this author
Apr 30 2008 2:16PM messages near this date
Re: [TCLCORE] Tcl byte code compiler | Re: [TCLCORE] [MACTCL] Woeful canvas performance 8.5.2
Hi Jasper,

On 30/04/2008, at 14:08, Jasper Taylor wrote:

>  I recently installed the ActiveTcl 8.5.2 distribution on my C2D
>  Macbook in the hope that it would fix some problems in graphical
>  performance that I have been having with 8.4.17. To my dismay, it was
>  far, far worse! Here is a little code snippet to make 10000 items on a
>  canvas...
> 
>  pack [canvas .c -width 1000 -height 1000 -bg \#ffaaff]
>  for {set y 0} {$y < 1000} {incr y 10} {
>       for {set x 0} {$x < 1000} {incr x 10} {
>           .c create line $x $y [expr $x+5] [expr $y+5]
>       }
>  }
> 
>  Run this, and you will find that resizing the wish window takes about
>  1 second when the whole canvas is displayed, and proportionally less
>  when less of the canvas is showing. On 8.4.x you get comparable
>  performance when you reduce the increments to 3, thus displaying more
>  than 10 times as many items. And under Windows and Linux there is no
>  noticeable delay at all even at this setting.

I cannot reproduce the difference you see between 8.4 and 8.5 (resp  
8.6), I get essentially the same performance from both branches, c.f.  
timings below (from modified script at msg end).

I do see > 8x worse performance compared to TkX11 on the same box, to  
some extent this is due to CoreGraphics drawing being slower in this  
specific case (drawing many short lines), however profiling reveals  
that most of time (> 60%) is in fact spent in repeated drawing  
environment setup and teardown and only about 30% of the time is  
spent actually drawing lines (c.f. Shark profiles below).

Unfortunately this is not something we can easily avoid in general  
with the current Tk architecture based on Xlib (resp. Xlib  
emulation). Every single line of the 6400 in the modified script  
below is drawn by the generic canvas code via a call to XDrawLines  
(from DisplayLine called in a loop from DisplayCanvas).

Inside the TkAqua XDrawLines implementation we cannot reliably tell  
that we are being called in a loop to draw into the same canvas over  
and over and so have to setup and teardown the graphics environment  
in every call, which is expensive (particularly color and clipping  
setup as shown below).

I think it will take modification of the generic code to fix this  
issue, e.g. DisplayCanvas could call a setup/teardown routine before/ 
after its item drawing loop.
Please file a bug asking for this in the Tk Tracker to remind me to  
look into it.

In the longer term the only good way IMO to fix these types of issues  
will be to move away from directly calling Xlib in Tk (and relying on  
Xlib emulation on non-X11 platforms) and to introduce a Tk drawing  
layer that matches up better with the various drawing APIs that we  
target; e.g. the issue at hand traces down to the fact that  
CoreGraphics uses a PostScript-style stack of graphics states  
specific to a drawable, whereas Xlib (and hence Tk) use a GC graphics  
context that is transportable between drawables.

In the meantime, you may want to try tweaking the following magic  
variables (c.f. tk/macosx/README for details):

- disable CG antialiasing (slows things down in the timings below but  
depending on the nature of your drawing YMMV)
	set tk::mac::CGAntialiasLimit 1000
- disable CG drawing entirely (i.e. fallback to QuickDraw and all the  
associated limitations esp. w.r.t wide line drawing)
	set tk::mac::useCGDrawing 0

If your main concern is performance during window resizing, you can  
disable live resizing by removing 'liveResize' from the window  
attributes e.g. via
	tk::unsupported::MacWindowStyle style . document {standardDocument}

HTH

Cheers,

Daniel

-- 
** Daniel A. Steffen                   **
** <mailto:das@[...].net>   **


8.6a0-CG:	435207.7974 microseconds per iteration
8.6a0-CGnoAA:	441955.7887 microseconds per iteration
8.6a0-QD:	302942.9803 microseconds per iteration

8.6a0-X11:	50522.2977 microseconds per iteration

8.4.19-CG:	435572.9 microseconds per iteration
8.4.19-CGnoAA:	436431.6 microseconds per iteration
8.4.19-QD:	301539.9 microseconds per iteration


- 42.1% TkMacOSXSetupDrawingContext (tktest)
- 33.4% XDrawLines (tktest)
- 20.3% TkMacOSXRestoreDrawingContext (tktest)

+ 30.4% CGContextStrokePath (CoreGraphics)
| - 30.4% XDrawLines (tktest)
+ 7.6% CGContextSynchronize (CoreGraphics)
| - 7.3% TkMacOSXRestoreDrawingContext (tktest)
| - 0.3% QDEndCGContext (QD)
+ 7.3% QDEndCGContext (QD)
| - 7.3% TkMacOSXRestoreDrawingContext (tktest)
+ 6.2% HIShapeReplacePathInCGContext (HIServices)
| - 6.2% TkMacOSXSetupDrawingContext (tktest)
+ 5.8% CGContextSetRGBFillColor (CoreGraphics)
| - 5.8% TkMacOSXSetupDrawingContext (tktest)
+ 5.5% doClip (CoreGraphics)
| - 5.5% TkMacOSXSetupDrawingContext (tktest)
+ 3.4% CGContextSetRGBStrokeColor (CoreGraphics)
| - 3.4% TkMacOSXSetupDrawingContext (tktest)
+ 3.3% HIShapeCreateIntersection (HIServices)
| - 3.3% TkMacOSXSetupDrawingContext (tktest)
+ 3.0% CGContextMoveToPoint (CoreGraphics)
| - 1.6% HIShapeReplacePathInCGContext (HIServices)
| - 1.5% XDrawLines (tktest)
+ 2.9% QDBeginCGContext (QD)
| - 2.8% TkMacOSXSetupDrawingContext (tktest)
+ 2.5% HIShapeCreateWithRect (HIServices)
| - 2.5% TkMacOSXSetupDrawingContext (tktest)
+ 2.1% QDSwapPort (QD)
| - 1.1% TkMacOSXRestoreDrawingContext (tktest)
| - 0.9% TkMacOSXSetupDrawingContext (tktest)
+ 2.1% TkMacOSXSetupDrawingContext (tktest)
| - 2.1% XDrawLines (tktest)
+ 2.1% CGSReleaseRegion (CoreGraphics)
| - 1.1% TkMacOSXRestoreDrawingContext (tktest)
| - 0.9% TkMacOSXSetupDrawingContext (tktest)
+ 1.9% SyncCGContextOriginWithPort (QD)
| - 1.9% TkMacOSXSetupDrawingContext (tktest)
+ 1.5% TkMacOSXRestoreDrawingContext (tktest)
| - 1.5% XDrawLines (tktest)


package require Tk
proc canvtime {l} {
     #exec chudRemoteCtrl -s "[info patchlevel]-$l"
     puts stderr "[info patchlevel]-$l:\t[time {
	.c configure -bg {#ffffff}
         update idletasks
	.c configure -bg {#ffaaff}
	update idletasks
     } 10]"
     #exec chudRemoteCtrl -e
}
wm geom . 820x820
pack [canvas .c -width 800 -height 800 -bg {#ffaaff}]
for {set y 0} {$y < 800} {incr y 10} {
      for {set x 0} {$x < 800} {incr x 10} {
	 .c create line $x $y [expr {$x+5}] [expr {$y+5}]
      }
}
update
if {[tk windowingsystem] eq "aqua"} {
     canvtime CG
     set tk::mac::CGAntialiasLimit 1000
     canvtime CGnoAA
     set tk::mac::useCGDrawing 0
     canvtime QD
} else {
     canvtime X11
}
exit


-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Tcl-Core mailing list
Tcl-Core@[...].net
https://lists.sourceforge.net/lists/listinfo/tcl-core
Thread:
Daniel A. Steffen
Mats Bengtsson

Privacy Policy | Email Opt-out | Feedback | Syndication
© 2004 ActiveState, a division of Sophos All rights reserved