Canvas efficiency
in [TCL]
|
Prev: Problem Setting Color in ttk combobox
Next: wm geometry
From: Jeff Godfrey on 1 May 2010 20:39 On 5/1/2010 7:15 PM, tomk wrote: > There are some thinks that I think will kill the performance > of the canvas and I'm wondering if you for instance have binding on > some of the items or have window items? Hi Tom, No, I don't have any item bindings and I'm not using any window items. I'm displaying CAD/CAM geometry, so my canvas items currently consist of simple lines, arcs, ovals (for circles) and a 6x6 image item for point geometry. > As I recall panning never had > a problem during any of my test but zooming did eventually slow down. Yep, my experience mostly mimics that as well. > The slowness occurred when large numbers of rectangles were displayed > but as I zoomed in the performance improved so display list management > seemed to be handled in some reasonable manner. Yeah, again, I'd agree with the above. > Also, I found that the tagging system seemed to work with out much > performance impact. My experience differs here. A previous version of this app uses tags heavily to manage the geometry (say, about 6 tags per entity), and there are definitely some bottlenecks due to the tag management. For this version, I'm attempting to completely eliminate tagging except for a few special cases. Instead, I'm managing everything in an in-memory SQLite database. So far, so good - but I still have some machinery to add, so I'm keeping my fingers crossed that I don't hit any major bottlenecks... > I used tags on all the rectangles to keep track of > their corner coordinates because I didn't want to run the risk of > having round off errors in the display system mess with the coordinate > accuracy. Well, I keep the *real* geometry data in the SQLite database, which is used for most things in the app. However, for the display, zooming, and panning of the data, I do allow the canvas to mess with the item coordinates. So far, it hasn't caused me any issues. The previous version of the app also did this, so I don't expect any real problems here... Thanks, Jeff
From: Jeff Godfrey on 1 May 2010 20:47 On 5/1/2010 10:03 AM, Donal K. Fellows wrote: > I doubt that it is the computation of the current item; that happens > whenever you move the mouse anyway and so would be sluggish even > without the selection rectangle. It's more likely to be a problem with > redraws, probably caused ultimately by the sheer number of items. Yeah, this was also suggested by Alex and is the general direction taken by the thread after my initial post. Further testing seems to corroborate that fact. > > One trick I've used in the past (with Tk 4.0 in fact) was to create > custom canvas items (not that difficult) so that the number of items > was reduced and I could use more efficient code for handling the item > geometry calculations. Thanks for the suggestion, though I'm not sure there's any gain to be had in this case. I'm displaying CAD/CAM geometry, which is naturally made up of line, arc, spline, and point data. So, the existing canvas items seem to be a pretty good fit. > If you're using a lot of items to represent > single logical entities, it may well be better to do something > similar. Thanks, I'll keep that in my back pocket, but I don't see a use for it in this case. > Another technique that I remember (but never used) is that there was > an extension which allowed you to group many items together. I don't > remember exactly what it was called though. Ultimately, I need to be able to reference each individual entity separately, so this probably wouldn't work for me either. Thanks for the input. Jeff
From: Donal K. Fellows on 2 May 2010 11:29 On 2 May, 01:39, Jeff Godfrey <jeff_godf...(a)pobox.com> wrote: > On 5/1/2010 7:15 PM, tomk wrote: > > Also, I found that the tagging system seemed to work with out much > > performance impact. > > My experience differs here. A previous version of this app uses tags > heavily to manage the geometry (say, about 6 tags per entity), and there > are definitely some bottlenecks due to the tag management. For this > version, I'm attempting to completely eliminate tagging except for a few > special cases. Instead, I'm managing everything in an in-memory SQLite > database. So far, so good - but I still have some machinery to add, so > I'm keeping my fingers crossed that I don't hit any major bottlenecks... OK, the one area where care needs to be taken is with tags. The issue is that each unique tag name is a Tk_Uid, and so never deallocated. If you've got lots of tags (especially lots of near-unique tags) then you've got a memory leak. (Also, it's faster to reconfigure an existing item than to create a new one; that can have an effect but maybe not in your case.) You say you're now managing the information model in a DB; that should be better. Donal.
From: Alexandre Ferrieux on 2 May 2010 12:13 On May 2, 5:29 pm, "Donal K. Fellows" <donal.k.fell...(a)manchester.ac.uk> wrote: > > OK, the one area where care needs to be taken is with tags. The issue > is that each unique tag name is a Tk_Uid, and so never deallocated. If > you've got lots of tags (especially lots of near-unique tags) then > you've got a memory leak. (Also, it's faster to reconfigure an > existing item than to create a new one; that can have an effect but > maybe not in your case.) You say you're now managing the information > model in a DB; that should be better. And well before this leak hurts you, the intrinsic linearity of lookup- by-tag leads to disappointing performance. It is also linear on the number of tags per given item, which doesn't help things either :(. All in all, any sizeable app is well advised to use external tools for bulk item management (lsts, arrays, dicts, databases). -Alex
From: tomk on 2 May 2010 20:12
> > Also, I found that the tagging system seemed to work with out much > > performance impact. > > My experience differs here. A previous version of this app uses tags > heavily to manage the geometry (say, about 6 tags per entity), and there > are definitely some bottlenecks due to the tag management. For this > version, I'm attempting to completely eliminate tagging except for a few > special cases. Instead, I'm managing everything in an in-memory SQLite > database. So far, so good - but I still have some machinery to add, so > I'm keeping my fingers crossed that I don't hit any major bottlenecks... > > > I used tags on all the rectangles to keep track of > > their corner coordinates because I didn't want to run the risk of > > having round off errors in the display system mess with the coordinate > > accuracy. > > Well, I keep the *real* geometry data in the SQLite database, which is > used for most things in the app. However, for the display, zooming, and > panning of the data, I do allow the canvas to mess with the item > coordinates. So far, it hasn't caused me any issues. The previous > version of the app also did this, so I don't expect any real problems > here... After thinking about the problem a little more and looking at the docs for canvas I think my memory may be a bit off (I don't have the code anymore :( to check what I did). I think I used the item id (not a tag) as an array index which means I didn't use any tags (except for items that were being edited, etc.). Item id's are unique and is equivalent to a tag in all the commands. tomk |