Canvas efficiency
in [TCL]
|
Prev: Problem Setting Color in ttk combobox
Next: wm geometry
From: Jeff Godfrey on 2 May 2010 20:29 On 5/2/2010 7:12 PM, tomk wrote: > 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. Yeah, the obvious gain of tags over item ID's is that you can easily "group" canvas items together via a common tag and operate on them all at once. I'm using the item ID's as my link back to the SQL database. That way, I can still group things as necessary, but don't bog down the app with tens (or even hundreds) of thousands of tags. That said, I do miss tags for things like setting item-type visibility. What I would normally do like this: ..c itemconfigure line -state hidden I now do like this (since I'm not using tags): render::setItemTypeVisibilityState .c line hidden which does this under the covers... dbGeo eval {SELECT renderID FROM render_xref WHERE type = $dataType} { $c itemconfigure $renderID -state $dataState } It seems that it's hard to outrun the tagging mechanism while iterating over (and configuring) thousands of entities in a loop... Jeff
From: Uwe Klein on 3 May 2010 04:46 Jeff Godfrey wrote: > .c itemconfigure line -state hidden I like to handle visibility via a blinder rectangle. raise lower items via tags in relation to the blinder. uwe
From: tomk on 3 May 2010 12:05 Jeff, > I'm using the item ID's as my link back to the SQL database. That way, > I can still group things as necessary, but don't bog down the app with > tens (or even hundreds) of thousands of tags. My project was killed before I got to the point where I needed to do grouping. In my application the groups would have been called cells and there was the possibility that they could be arrayed (i.e. replicated in a grid). Actually replication would have driven the item counts to unmanageable levels so the strategy I was considering (but didn't implement) was to draw the group into a buffer, convert it to a bit map and then place it as an image. I believe this procedure is commonly used in structure drawing packages. When a user selects a grouped item its boundary is highlighted with a rectangle and the grouped item can then be "entered" using a group edit command when the group edit command is executed the image is replaced with the actual draw items (only at the location selected) and the user then edits those items. When the group is closed the modified items are converted to an image and all locations are updated. tomk
From: tomk on 3 May 2010 12:20 On May 2, 5:29 pm, Jeff Godfrey <jeff_godf...(a)pobox.com> wrote: > On 5/2/2010 7:12 PM, tomk wrote: > > > 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. > > Yeah, the obvious gain of tags over item ID's is that you can easily > "group" canvas items together via a common tag and operate on them all > at once. > > I'm using the item ID's as my link back to the SQL database. That way, > I can still group things as necessary, but don't bog down the app with > tens (or even hundreds) of thousands of tags. > > That said, I do miss tags for things like setting item-type visibility. > What I would normally do like this: > > .c itemconfigure line -state hidden > > I now do like this (since I'm not using tags): > > render::setItemTypeVisibilityState .c line hidden > > which does this under the covers... > > dbGeo eval {SELECT renderID FROM render_xref WHERE type = $dataType} { > $c itemconfigure $renderID -state $dataState > > } > > It seems that it's hard to outrun the tagging mechanism while iterating > over (and configuring) thousands of entities in a loop... > > Jeff Jeff, Forgot to mention that I also implemented (because it was required) grid snapping. The actual snapping is done in the point placement calculations and isn't part of the graphics but to visualize the snap grid I placed rectangles that were 1x1 pixel at each of the grid points. The grid was removed and recalculated on pan and zoom operations. In the grid placement code I aborted if the number of grid points exceeded some threshold. With this approach I saw now appreciable impact on redraw speed. tomk
From: Jeff Godfrey on 3 May 2010 13:03
On 5/3/2010 11:05 AM, tomk wrote: > My project was killed before I got to the point where I needed to do > grouping. In my application the groups would have been called cells > and there was the possibility that they could be arrayed (i.e. > replicated in a grid). Actually replication would have driven the item > counts to unmanageable levels so the strategy I was considering (but > didn't implement) was to draw the group into a buffer, convert it to a > bit map and then place it as an image. Tom, Thanks for the additional input. Alex F. and I have been discussing other possibilities off-line, and various tricks with geometry-to-image conversion have come up (off-line and in this thread). I think any method involving to-image conversion quickly falls apart in this app, as everything can be dynamically zoomed via selection window or mouse wheel. Since the visible image would need to be recreated after each zoom change, and there doesn't seem to be a fast (enough) way to do that, I don't see this method as usable for me. 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. Still experimenting... Jeff |