[PD-dev] bug when redrawing gop within gop inside a closed sub-patch

[Ivica Ico Bukvic]

> 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