Canvas efficiency
in [TCL]
|
Prev: Problem Setting Color in ttk combobox
Next: wm geometry
From: Jeff Godfrey on 4 May 2010 15:05 On 5/4/2010 1:29 PM, tomk wrote: >> Another method that should hold huge gains (suggested by Alex) with >> regard to this bottleneck would be to eliminate any geometry that's >> deemed too-small at the current zoom scale (which, really, is a lot of >> it). Unfortunately, as usual, the problem lies in detecting and acting >> upon that geometry in a manner that's fast enough to not kill the User >> experience. > > Before you write the code to do the trimming of geometries be sure to > check the canvas implementation. My guess is that the canvas already > implements some form of visibility trimming as part of the clipping > algorithm for the window. > tomk Looking at the code, that doesn't appear to be the case. It looks like if the item is within the bounds that needs to be redrawn and it's not currently hidden, it gets redrawn. I don't see any other culling going on. That said, I have zero experience with the Tk sources, so maybe there's more at work here than first meets the eye... Jeff
From: tomk on 4 May 2010 15:48 Jeff, One last comment.... As I recall the problems associated with doing grouping eventually lead me to reconsider using the canvas. What I was considering at the end of the project was a rewrite using tkZinc, see link below. http://www.tkzinc.org/tkzinc/pmwiki.php?n=Main.HomePage This extension seemed to be just what was needed. It's a 2D package that appears to support grouping. I didn't actually get to the point where I used it but I think it's worth a look. Tom K.
From: Jeff Godfrey on 4 May 2010 16:30 On 5/4/2010 2:48 PM, tomk wrote: > Jeff, > > One last comment.... > > As I recall the problems associated with doing grouping eventually > lead me to reconsider using the canvas. What I was considering at the > end of the project was a rewrite using tkZinc, see link below. > > http://www.tkzinc.org/tkzinc/pmwiki.php?n=Main.HomePage > > This extension seemed to be just what was needed. It's a 2D package > that appears to support grouping. I didn't actually get to the point > where I used it but I think it's worth a look. Tom, Thanks. I'm familiar with TkZinc (and Tkpath)- both of which have some attractive features for my current application. I looked seriously at TkZinc for this app quite some time ago, but eventually moved away from it, though I don't remember why. Likewise, I had high hopes for Tkpath, but with the untimely passing of Mats, the project seems to have lost much of its thrust. Anyway, I am looking at both packages again to determine their current suitability for my situation. In the mean time, I have had some success with culling geometry that's too small to be interesting during the zooming operation. Basically, I adjust the -state of a subset of my items based on the current scale and each entity's original dimension. That has the effect of turning off a large percentage of my geometry when it's all within the screen bounds at once ("zoom all"). The advantage is that there are far less items for the canvas to redraw during the zoom-window drag operation, so it's snappier. The disadvantage is that finding and tweaking the -state of the affected objects costs cycles in the zooming code. The net effect is a a win, but I'm still not happy with the overall results. Jeff
From: Shaun Deacon on 4 May 2010 19:41 > I looked seriously at TkZinc for this app quite some time ago, but > eventually moved away from it, though I don't remember why. > > Likewise, I had high hopes for Tkpath, but with the untimely passing of > Mats, the project seems to have lost much of its thrust. > > Anyway, I am looking at both packages again to determine their current > suitability for my situation. Jeff, Just out of curiosity, If you're looking at TkZinc and TkPath again perhaps you are considering a major overhaul for your project ... Did you ever consider making a custom C or C++ widget to replace your canvas ? I recognize this would be more work, but the display performance would be significantly better when dealing with a very large number of objects and your 'zoom rectangle' issues would disappear too... Shaun
From: Jeff Godfrey on 4 May 2010 20:40
On 5/4/2010 6:41 PM, Shaun Deacon wrote: > Just out of curiosity, If you're looking at TkZinc and TkPath again > perhaps you are considering a major overhaul for your project ... Hi Shaun, Actually, the render code for this project is completely isolated from everything else, and it's really fairly light weight. So, should I decide to switch out the canvas for one of the other two contenders, it shouldn't be too much effort. That said, I was just playing with TkZinc again this afternoon, and it appears to have a serious text rotation bug. > Did you ever consider making a custom C or C++ widget to replace your > canvas ? I recognize this would be more work, but the display > performance would be significantly better when dealing with a very > large number of objects No, this isn't something I've really ever considered seriously. Maybe I should, but I hope not to have to resort to that. > and your 'zoom rectangle' issues would > disappear too... Speaking of the "zoom rectangle" issue - I just resolved it (not 30 mins ago) in a manner that I'm quite happy with (at least so far). Prodded by some comments made by Alex F. in an offline exchange, I realized that in order to eliminate the sluggish rectangle drag issue, what I really needed was for the on-screen zoom box to *not* be a canvas item. Well, once I started thinking along those lines, it all fell into place pretty quickly. Now, I'm using an unmanaged, partially-transparent toplevel window for the zoom box. So, no matter how complex the canvas is, it doesn't impact my box drag. And, I think it even looks better as a shaded rectangle rather than just a wireframe. It seems so obvious now... ;^) With that resolved, I'm now removing all of my size culling code, as it kind of cluttered up my otherwise simple render code and it still had a few unresolved issues. Jeff |