Woeful canvas performance 8.5.2

[Jasper Taylor]

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.

Does anyone have any idea why this should be? And is it being fixed?  
Could I help? I've written lots of TclTk and c++ code but done no Mac  
Carbon or Cocoa development.

        --Jasper


-------------------------------------------------------------------------
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-mac mailing list
tcl-mac@...
https://lists.sourceforge.net/lists/listinfo/tcl-mac

[Jasper Taylor]

Tried it on the only other mac I have access to, a Mac Mini G4 800MHz
running OSX 10.3, and the performance is worse than on the Macbook,
showing the 'colour wheel of death' a lot.
Could this be a Tk 8.5.2 vs 8.5.1 issue? Or more likely to be down to
the individual machines' graphics hardware?
        --Jasper

On 30 Apr 2008, at 15:01, Kevan Hashemi wrote:

> The window re-sizes as fast as I can move the mouse.


-------------------------------------------------------------------------
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-mac mailing list
tcl-mac@...
https://lists.sourceforge.net/lists/listinfo/tcl-mac

[Kevan Hashemi]

Dear Jasper,

To help other people track down your problem, I executed your code
snippet on TclTk 8.5.1, universal binaries, built from sources on MacOS
10.4.11, 1.3GHz PPC G4. I changed -height 1000 to -height 500 so the
window would fit on my screen for re-sizing.

pack [canvas .c -width 1000 -height 500 -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]
      }
}

The window re-sizes as fast as I can move the mouse.

Yours, Kevan

--
Kevan Hashemi, Electrical Engineer
Physics Department, Brandeis University
http://alignment.hep.brandeis.edu/

-------------------------------------------------------------------------
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-mac mailing list
tcl-mac@...
https://lists.sourceforge.net/lists/listinfo/tcl-mac

[Kevin Walzer-5]

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.
>
> Does anyone have any idea why this should be? And is it being fixed?  
> Could I help? I've written lots of TclTk and c++ code but done no Mac  
> Carbon or Cocoa development.
>
> --Jasper

Performance with Tk 8.5.0 on my 2.16 DC Macbook, 1GB ram, OS 10.5.2, is
quite slow on window resize. I have no idea why.


--
Kevin Walzer
Code by Kevin
http://www.codebykevin.com

-------------------------------------------------------------------------
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-mac mailing list
tcl-mac@...
https://lists.sourceforge.net/lists/listinfo/tcl-mac

[David Zolli]

Le 30 avr. 08 à 15:51, Jasper Taylor a écrit :

> Could this be a Tk 8.5.2 vs 8.5.1 issue? Or more likely to be down to
> the individual machines' graphics hardware?

On my MacBook Core 2 Duo 2.16 - 1Gb Ram - OS 10.5.2 with all etcl
versions from rc23 (8.4.16) to rc28 (8.5.2) that's allways slow.

--
David Zolli
kroc@...
http://www.kroc.tk



-------------------------------------------------------------------------
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-mac mailing list
tcl-mac@...
https://lists.sourceforge.net/lists/listinfo/tcl-mac

[Jeff Hobbs]

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 find 8.4.18 and 8.5.2 about equally slow on my MBP 2.6ghz running
Leopard.  There is probably some poor algorithm handling line
redraw/refresh on OS X that isn't the same on Win/Lin.  Don't know any
more off the top of my head.

Jeff

-------------------------------------------------------------------------
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-mac mailing list
tcl-mac@...
https://lists.sourceforge.net/lists/listinfo/tcl-mac

[Philip Aker-3]

On 08-04-30, at 06:51, Jasper Taylor wrote:

> Tried it on the only other mac I have access to, a Mac Mini G4 800MHz
> running OSX 10.3, and the performance is worse than on the Macbook,
> showing the 'colour wheel of death' a lot.
> Could this be a Tk 8.5.2 vs 8.5.1 issue? Or more likely to be down to
> the individual machines' graphics hardware?

I ran your script on my 1.5 GHz Intel mini and it was slow. The only  
time I notice things about its graphics capabilities is when running  
Quartz composer files. Then the machine starts to whir excessively and  
get very hot, but it still draws fine.

Philip Aker
echo astwta@...@nl | tr a-z@. p-za-o.@

Sent from my SE/30


-------------------------------------------------------------------------
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-mac mailing list
tcl-mac@...
https://lists.sourceforge.net/lists/listinfo/tcl-mac

[Daniel A. Steffen]

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@...>  **


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-mac mailing list
tcl-mac@...
https://lists.sourceforge.net/lists/listinfo/tcl-mac

[Mats Bengtsson-5]

On Wed, Apr 30, 2008 at 11:16 PM, Daniel A. Steffen
<das@...> wrote:

> Hi Jasper,
>
>
>  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.
>

Maybe this will be possible in my new tkp::canvas (tkpath) where the drawing
abstractions are not tied to X11, but are using the native graphics engine like:

TkPathContext TkPathInit(Tk_Window tkwin, Drawable d)
TkPathMoveTo(TkPathContext ctx, double x, double y)
TkPathLineTo(TkPathContext ctx, double x, double y)
...

But in that case I need some feedback from you when I have something to show.
Nothing in cvs right now except the old style tkpath.

Mats

-------------------------------------------------------------------------
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-mac mailing list
tcl-mac@...
https://lists.sourceforge.net/lists/listinfo/tcl-mac