Canvas efficiency
in [TCL]
|
Prev: Problem Setting Color in ttk combobox
Next: wm geometry
From: Jeff Godfrey on 30 Apr 2010 18:51 On 4/30/2010 5:13 PM, Shaun Deacon wrote: >> I think either might have some merit, except for the fact that it's >> taking 35+ seconds to take a snapshot of the canvas contents (see >> previous posts). >> >> Jeff > > Yes, this would definitely make the user experience horrible... > > Sorry, I don't have any other suggestions at the moment. Although I'm > still interested in whether anyone can give an explanation for your > original problem (regarding what is happening under the canvas hood > that might be the cause) Shaun, Thanks for all you're input - I appreciate it. Regarding the underlying cause, I assume Alex nailed it in his original response to the thread (finding and refreshing the areas marked as dirty during the drag). Did you miss that, or do you have reason to believe that's not the real cause? Ah, I guess the fact that you seem to have experienced a similar issue with a completely empty canvas might make you think something else is at work here... Jeff
From: Shaun Deacon on 30 Apr 2010 20:52 > Ah, I guess the fact that you seem to have experienced a similar issue > with a completely empty canvas might make you think something else is at > work here... > > Jeff Yes, that was it... As you say, I think Alex's explanation covers your case. For my empty canvas drag, I was just curious if there might be another reason. Shaun
From: Alexandre Ferrieux on 1 May 2010 10:14 On Apr 30, 9:13 pm, Will Duquette <w...(a)wjduquette.com> wrote: > On Apr 30, 9:43 am, Jeff Godfrey <jeff_godf...(a)pobox.com> wrote: > > > > > > > On 4/30/2010 11:21 AM, Alexandre Ferrieux wrote: > > > > On Apr 30, 5:53 pm, Jeff Godfrey<jeff_godf...(a)pobox.com> wrote: > > >> On 4/30/2010 10:26 AM, Jeff Godfrey wrote: > > > >>> The magnitude of the effect is directly > > >>> related to the density of canvas items at the current mouse location > > >>> (more items = deeper water). > > > >> Hmmm... After a bit more testing, the above isn't quite accurate. It > > >> seems the effect is more related to amount of canvas geometry found > > >> "within" the rectangle I'm dragging out. As the rectangle surrounds > > >> more geometry, the effect gets worse. > > > >> So, now I'm wondering whether the update of the "current" item is even > > >> related, since I can make the effect much worse without ever having any > > >> geometry at the mouse position. > > > > If BLT is not an option and you can restrict yourself to single pixels > > > or rectangular dots, then a bitmap/photo image may be the way to go. > > > You can overlay it with your selection rectangle and it will refresh > > > in no time. > > > Alex, > > > Thanks for the input (as usual)... ;^) > > > Currently, I'd have to say that BLT is not an option, but I'm not > > following your above suggestion. Do you mind trying again? > > > Thanks, > > > Jeff > > Well, you could try this: > > 1. Using Img, you can capture the visible area of the canvas as a > Tk image. > 2. Delete the contents of the canvas. (You're going to redraw it > anyway, once you get the rectangle, right?) > 3. Position the Tk image on the visible area of the canvas. Now > there's no geometry to slow things down. > 4. When they've selected the rectangle, delete the image, and redraw. Nice idea. Of course, as the rest of the thread shows, the problem is that the creation of the snapshot takes time too (thousands of items to draw again in right order, while re-rendering the canvas to the offscreen pixmap). But this makes me think of a possible addition to Tk that could help here. When a menu pops-up, the display system is told to "save under", meaning just grab the pixels that are about to be hidden, but without asking the app to regenerate them for that. That's a big difference, especially with complex graphics. So, could we do the same here, leveraging the same underlying primitive ? -Alex
From: Donal K. Fellows on 1 May 2010 11:03 On 30 Apr, 16:26, Jeff Godfrey <jeff_godf...(a)pobox.com> wrote: > With large data sets (say, upwards of 25,000 canvas entities), I notice > a delay when dragging the zoom rectangle out over the canvas contents. > The delay makes the whole operation seem "sluggish", as if running > through waist-deep water. The magnitude of the effect is directly > related to the density of canvas items at the current mouse location > (more items = deeper water). 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. 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. If you're using a lot of items to represent single logical entities, it may well be better to do something similar. 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. Donal.
From: tomk on 1 May 2010 20:15
On Apr 30, 8:26 am, Jeff Godfrey <jeff_godf...(a)pobox.com> wrote: > I'm using a canvas as the core display widget for a geometry viewer. > The app supports panning and zooming of the canvas contents. One > supported zoom method allows the User to drag out a rectangle over the > area to be zoomed, which is then scaled to fit within the canvas view. > > With large data sets (say, upwards of 25,000 canvas entities), I notice > a delay when dragging the zoom rectangle out over the canvas contents. > The delay makes the whole operation seem "sluggish", as if running > through waist-deep water. The magnitude of the effect is directly > related to the density of canvas items at the current mouse location > (more items = deeper water). > > I assume this is related to the scanning that must be going on under to > covers in order to keep the item tagged as "current" up-to-date. > > So, my questions: > > 1. Am I correct regarding the reason for the delay? > 2. Do other factors play a large role? If so, what are those factors? > > Assuming my guess is correct, it'd be nice to control when the canvas > does the automatic scanning. For instance, during a zoom drag > operation, I don't care about the current item, and I can't really > afford the CPU cycles needed to find it. If I could, I'd turn the > scanning off at the beginning of the zoom operation and turn it back on > at the end. > > AFAIK, that's not currently possible, but I wonder if it might be a > worthy feature suggestion? Thoughts? > > Any other suggestions to improve the situation with existing > capabilities are appreciated. Heck, if it were possible, I'd think > overlaying a temporary, transparent rectangle on top of the data might > work nicely too (as it'd always be "current"), but again, AFAIK, I can't > do that today. > > Thanks, > > Jeff Jeff, Almost 10 years ago I tested the canvas with up to 100K rectangle (note only rectangle) and found that it didn't have any real performance problems until I hit something like 75K items. With the much better hardware that we have today I wouldn't have expected your result. 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? If so I'm pretty sure your performance will be sluggish. You might try some more testing to determine the root cause of the problem. As I recall panning never had a problem during any of my test but zooming did eventually slow down. 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. Also, I found that the tagging system seemed to work with out much performance impact. 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. Tom K. |