Canvas efficiency
in [TCL]
|
Prev: Problem Setting Color in ttk combobox
Next: wm geometry
From: Shaun Deacon on 5 May 2010 13:13 > 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. What a great idea, very cool ... good luck with the rest of your project. Shaun
From: Alexandre Ferrieux on 5 May 2010 15:54 On May 5, 2:40 am, Jeff Godfrey <jeff_godf...(a)pobox.com> wrote: > > 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. One thing worth trying could be to use another window that's not a toplevel, but another Tk widget (like a frame) inside the same toplevel (or even a child of the canvas). Two variants: (a) a 'window' item in the canvas (b) a child of the canvas, managed by [place] Both methods generate something that 'floats' above the canvas, but for the performance of the redraw I cannot test, since in my environment (Fedora 12, icewm) there is no save-under among toplevels, hence I get a slow redraw in all cases :/ I understand that your Windows7 always saves under a toplevel (or draws through an offscreen buffer); I'd like to know if it does this for (a) and (b). -Alex
From: Jeff Godfrey on 5 May 2010 16:49 On 5/5/2010 2:54 PM, Alexandre Ferrieux wrote: > One thing worth trying could be to use another window that's not a > toplevel, but another Tk widget (like a frame) inside the same > toplevel (or even a child of the canvas). Two variants: > > (a) a 'window' item in the canvas > (b) a child of the canvas, managed by [place] Alex, I just tried both of these under Win 7 using a Tk frame. Method (a) seems to perform roughly like my original code that used a canvas rectangle item for the zoom window. That is, it seems to get more sluggish as it covers more canvas data and less so as it covers fewer items. Method (b) was a little different. It seems to drag "out" without any delay, but then gets sluggish when dragging back. Hmmm.. That's a little awkward - here's an example... Say I start the drag in the upper-left corner of the canvas. I can drag to the lower right corner (thus covering all canvas items) with seemingly no delay. However, when I start to drag back toward the upper left again (revealing canvas items in the process), things start to get choppy. I assume this is just an experiment as opposed to another possibly viable method? Since, AFAIK, I can't make the frame translucent anyway, right? So, it blocks out everything beneath it in both test cases. Jeff
From: Alexandre Ferrieux on 5 May 2010 17:02
On May 5, 10:49 pm, Jeff Godfrey <jeff_godf...(a)pobox.com> wrote: > On 5/5/2010 2:54 PM, Alexandre Ferrieux wrote: > > > One thing worth trying could be to use another window that's not a > > toplevel, but another Tk widget (like a frame) inside the same > > toplevel (or even a child of the canvas). Two variants: > > > (a) a 'window' item in the canvas > > (b) a child of the canvas, managed by [place] > > Alex, > > I just tried both of these under Win 7 using a Tk frame. > > Method (a) seems to perform roughly like my original code that used a > canvas rectangle item for the zoom window. That is, it seems to get > more sluggish as it covers more canvas data and less so as it covers > fewer items. > > Method (b) was a little different. It seems to drag "out" without any > delay, but then gets sluggish when dragging back. Hmmm.. That's a > little awkward - here's an example... > > Say I start the drag in the upper-left corner of the canvas. I can drag > to the lower right corner (thus covering all canvas items) with > seemingly no delay. However, when I start to drag back toward the upper > left again (revealing canvas items in the process), things start to get > choppy. These observations show that (a) is less optimized than (b): the redraw in (a) is slow even though the covered area is growing, while in (b) it is what one would expect from a redraw-on-Expose. I interpret this as: (a) treats the window as a normal item despite its special floating nature, hence the similarity of performance with a vanilla rectangle. (b) computes the exposed area, and does the clipped redraw, *but* no offscreen buffer is used. So a secondary conclusion is that the offscreen buffer is (a) restricted to toplevels (b) restricted to Windows. XP ? 7 ? > > I assume this is just an experiment as opposed to another possibly > viable method? Since, AFAIK, I can't make the frame translucent anyway, > right? So, it blocks out everything beneath it in both test cases. Yes. My way of probing the mechanism without having a Win7 ;-) -Alex |