They're just sitting there without any animation or bindings on them.
Is this expected because of the number of objects I have on the
canvas?
I'm using a modern machine, Sempron 3000+ with a gig of ram on WinXP
SP2.
I'm using 8.3.5
Thanks :D
In our project we use the Tkzinc (http://www.tkzinc.org) extension. It
has a canvas like programming interface, and uses OpenGL for native
drawing. It runs without any problems on Windows and Linux (MacOS also
supported). In our application we draw up to 50000 ojects without any
performance problems.
Best regards
Nickotin
> In our project we use the Tkzinc (http://www.tkzinc.org) extension. It
> has a canvas like programming interface, and uses OpenGL for native
> drawing. It runs without any problems on Windows and Linux (MacOS also
> supported). In our application we draw up to 50000 ojects without any
> performance problems.
TkZinc looks really great, but I'm used to the canvas. 50k objects
sounds amazing though. I'll screw around with the canvas a bit and
see where the problem is coming from before moving.
> I'm using 8.3.5
Any reason not to use a Tcl 8.4.x version - say maybe 8.4.14? I would
expect that a version of Tk that is 4+ years old might be a bit slower
than the latest version...
I just like it... and I'm using a lot of windows extensions that I
have tested extensively with the exact binary I'm using. It all works
together nicely.
Anyway I'll make a test program later today and find out if it's the
rest of my code, or if X amount of objects really does make the canvas
unworkable. I'm just looking for a heads up, someone to tell me "the
canvas can handle X million so you're doing something wrong", or "oh
yeah that's a known deficiency, don't do that".
I would be surprised if your conclusion is: the canvas can handle x million,
I'm doing something wrong. Mind you, you may still be doing something wrong
:-)
We gave up on the canvas after trying to draw more than 10-20K objects and
moving/scrolling them. Not saying it's horrible - it's good for what it is.
But, rendering performance under heavy load is not one of its strengths. You
may be ok at 50K, but I wouldn't bet on it. We switched to a QT window
embedded in TK for the actual rendering, can do 1.5+M objects/sec (on an
Athlon64 3500).
Mind you, depending on what you're doing, putting 50k objects on screen
faster may be optimising the wrong thing (i.e. maybe you should be smarter
about WHAT you display, not faster in HOW you do it). But, that depends on
your needs, etc.
MH
> Anyway I'll make a test program later today and find out if it's the
> rest of my code, or if X amount of objects really does make the canvas
> unworkable. I'm just looking for a heads up, someone to tell me "the
> canvas can handle X million so you're doing something wrong", or "oh
> yeah that's a known deficiency, don't do that".
Here's some code that slows down panning (drag around with button-1
pressed) and also makes resizing the toplevel slow.
# generate random integer number in the range [min,max]
proc RandomInteger4 {min max} {
return [expr {int(rand()*($max-$min+1)+$min)}]
}
namespace eval ::largec:: {}
proc ::largec::init {} {
set t .largec
toplevel $t -bg red
canvas $t.c -bg black
pack $t.c -fill both -expand 1
set c $t.c
# panning
bind $c <ButtonPress-1> {%W scan mark %x %y}
bind $c <B1-Motion> {%W scan dragto %x %y 1}
set line_counts {}
for {set i 0} {$i < 500} {incr i} {
lappend line_counts [RandomInteger4 40 80]
}
set size 4
set count 0
foreach el $line_counts {
for {set i 0} {$i < $el} {incr i} {
set x1 [expr $size * $i]
set y1 [expr $count * $size]
set x2 [expr $x1 + $size]
set y2 [expr $y1 + $size]
$c create rect $x1 $y1 $x2 $y2 -fill yellow ;# -outline yellow
}
incr count
}
}
::largec::init
puts "number of canvas elements: [llength [.largec.c find withtag
all]]"