Canvas efficiency
in [TCL]
|
Prev: Problem Setting Color in ttk combobox
Next: wm geometry
From: Aric Bills on 30 Apr 2010 16:54 On Apr 30, 2:43 pm, Jeff Godfrey <jeff_godf...(a)pobox.com> wrote: > On 4/30/2010 3:20 PM, Aric Bills wrote: > > > In that case, how about this procedure: > > Aric, > > The ingenuity of this group is always quite impressive... ;^) > > Thanks for working up an example. Unfortunately, when I tried it here > is was completely non-responsive. Curious about why, I started digging > and found the culprit: > > The call to [image create photo ...] takes 32 seconds to return (doh!). > > That's running an AS build (8.5.8) under Win7 x64 and using v1.4 of > img::window. I really don't use the img extension, so I don't know if > it needs to be updated, if it's (nearly) broken on Windows, or something > else. > > Thoughts? > > Jeff Ouch. I'm running AS 8.6b1.1 on 32-bit OpenSUSE and version 1.4 of img::window. The [image create] command took 43483 microseconds here. But I guess if it doesn't work on Windows, it doesn't really help you. Sorry to hear that.
From: Jeff Godfrey on 30 Apr 2010 17:03 On 4/30/2010 3:54 PM, Aric Bills wrote: > Ouch. I'm running AS 8.6b1.1 on 32-bit OpenSUSE and version 1.4 of > img::window. The [image create] command took 43483 microseconds > here. But I guess if it doesn't work on Windows, it doesn't really > help you. Sorry to hear that. Just tried again using AS 8.6b1.1. The [image create] call took 37.5 secs, so that doesn't look workable in my environment. Thanks for taking a look anyway. Jeff
From: Shaun Deacon on 30 Apr 2010 17:24 > Thanks for the input. In my case though, it falls apart at #2, as I > don't ever delete the canvas contents until I'm through with them. It > takes too long to load the data for that to be workable. You could adapt #2 by 'serializing' the canvas data into a suitable Tcl list before deleting. Then just reset the canvas with the serialized data. I use this technique for saving/reloading the current display when a user exits/restarts my app... In my case it's much faster than rebuilding the display. Shaun
From: Jeff Godfrey on 30 Apr 2010 17:51 On 4/30/2010 4:24 PM, Shaun Deacon wrote: >> Thanks for the input. In my case though, it falls apart at #2, as I >> don't ever delete the canvas contents until I'm through with them. It >> takes too long to load the data for that to be workable. > > You could adapt #2 by 'serializing' the canvas data into a suitable > Tcl list before deleting. Then just reset the canvas with the > serialized data. I use this technique for saving/reloading the current > display when a user exits/restarts my app... In my case it's much > faster than rebuilding the display. > > Shaun Maybe, but with the potential amount of data here, my gut feel is that any method which tries to clear the canvas and rebuild it (from any source) is going to be akin to throwing the baby out with the bath water. That is, I think the User experience will be worse than just dealing with the original problem - which isn't really *that* bad, but noticeable... Another hybrid of the idea (that might be better in this case), would be take a snapshot of the canvas, *move* the data well off screen (which is relatively fast), replace the view with the snapshot, perform the window drag, and then scale, move the pre-moved data accordingly. That, or Aric's suggestion of using two canvases... 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
From: Shaun Deacon on 30 Apr 2010 18:13
> 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 |