Why would it be the cleaner thing to do? It's not like simpler, smaller commands are full of doorknob viruses. Tk has the commands on groups of items so that it acts on groups of items, I don't know why we're supposed to avoid that feature and call it cleaner.
Because of the same reason why I filed and corrected the redrawing bug in pd.tk that has been there for eons and which kept showing scrollbars when there should've been none (namely because when calculating bbox size the Tcl/Tk built-in call took into account all elements, including text which canvas is unable to apparently calculate properly).
For more info on this problem see: http://wiki.tcl.tk/4844
To quote pertinent part: #-------------------------------------------------------- # Get the size of all the items on the canvas. # # This is *really easy* using # $canvas bbox all # but it is also wrong. Non-scalable canvas # items like text and windows now have a different # relative size when compared to all the lines and # rectangles that were uniformly scaled with the # [$canvas scale] command. # # It would be better to tag all scalable items, # and make a single call to [bbox]. # Instead, we iterate through all canvas items and # their coordinates to compute our own bbox. #-------------------------------------------------------- set x0 1.0e30; set x1 -1.0e30 ; set y0 1.0e30; set y1 -1.0e30 ; foreach item [$canvas find all] { switch -exact [$canvas type $item] { "arc" - "line" - "oval" - "polygon" - "rectangle" { set coords [$canvas coords $item] foreach {x y} $coords { if { $x < $x0 } {set x0 $x} if { $x > $x1 } {set x1 $x} if { $y < $y0 } {set y0 $y} if { $y > $y0 } {set y1 $y} } } } }
Alternatively, search my previous post on pd-dev list regarding improved scrolling algorithm (it's included as part of that patch).
This has resulted in no observable change in performance here on my end. OTOH I now can put a number2 object with a large font (e.g. for GUI notification) in any corner of the window without scrollbars appearing for no apparent reason and potentially wreaking havoc in visual organization of content.
or simply refreshing entire canvas and trusting that tcl/tk is implemented so efficiently that its execution offsets time required for redundant redraws.
What about trusting that tcl/tk is implemented so efficiently that when you are picking each element in the manner that they are sorted already, and raising each of them separately to the top (thus changing the order of N cords N times in a row), tcl/tk would figure out that it has nothing to redraw?... I wouldn't even be sure that *any* toolkit would figure out that situation. Whereas for raise all_cords, tcl/tk guarantees it preserves the relative order of members of all_cords, so it is possible and likely that it will figure out that nothing has changed (but not certain).
This is IMHO the first valid argument against my suggested implementation you made so far and one I would agree with.
Either way, all this still leaves us with a bandaid solution that needs to be corrected (namely checking that canvas indeed exists before calling raise all_cords).
It seems to me then that encapsulating raise all_cords call into a function and prepending it with your suggested check ought to solve most if not all of the problems associated with this bug.
Ico