Canvas efficiency
in [TCL]
|
Prev: Problem Setting Color in ttk combobox
Next: wm geometry
From: Donal K. Fellows on 3 May 2010 13:47 On 03/05/2010 18:03, Jeff Godfrey wrote: > 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. Have you profiled the code yet? I'd hate us to be throwing effort at code that isn't the actual bottleneck... Donal.
From: Jeff Godfrey on 3 May 2010 14:10 On 5/3/2010 12:47 PM, Donal K. Fellows wrote: > Have you profiled the code yet? I'd hate us to be throwing effort at > code that isn't the actual bottleneck... Donal, I assume you're referring to the C-level code rather than the script, right? If so, no, not yet. Just attempting to build from source now. Once that's done, I'll see what I can do with regard to profiling. Jeff
From: Jeff Godfrey on 3 May 2010 17:27 On 5/3/2010 3:46 AM, Uwe Klein wrote: > 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, Another interesting idea, though there are some efficiency gains to be had by using [-state hidden], as the canvas seems to take some shortcuts with geometry in that state. With lots of canvas data, I need every efficiency boost I can get... Jeff
From: Alexandre Ferrieux on 3 May 2010 17:51 On May 3, 11:27 pm, Jeff Godfrey <jeff_godf...(a)pobox.com> wrote: > On 5/3/2010 3:46 AM, Uwe Klein wrote: > > > 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, > > Another interesting idea, though there are some efficiency gains to be > had by using [-state hidden], as the canvas seems to take some shortcuts > with geometry in that state. With lots of canvas data, I need every > efficiency boost I can get... And speaking of boosts here and there (random ideas): - integer coordinates (maybe it helps having exact verticals/ horizontals) - dotted lines by stippling instead of repeated segments - bitmap fonts (not antialiased) if many text items - tiny repeated circles/arcs -> images whenever possible - polylines instead of several lines whenever possible -Alex
From: tomk on 4 May 2010 14:29
> 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 |