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

Ivica Ico Bukvic ico at vt.edu
Sat Nov 21 23:11:38 CET 2009


> > So, if anyone is aware of the reason for its placement, it would be most
> > helpful to learn more about that before making the final decision
> > whether to keep/remove it.
> 
> Because objectboxes and messageboxes and atomboxes have
> become opaque, so
> the stacking order of wires does matter more. They have to stay on top in
> order to be more visible, yet the pd architecture is not sophisticated
> enough to allow pd to force all of its externals to draw all boxes _under_
> the wires.

Well, in that case the line in question is a band aid on the problem, not a
fix. 

Such a redraw call should not try to redraw all cords but only those that
are visible, otherwise you get potentially excessive error outputs  from
tcl/tk reporting that there is no such cord/canvas (e.g. for the ones
embedded in sub-patches) that bog pd down. If you have a large patch, you
can get literally hundreds of those per every GUI update that eat precious
cpu cycles.

There should be a loop that goes through all existing cords and checks
whether they are visible and if so, raises them. Otherwise, they should be
ignored.

Ico





More information about the Pd-dev mailing list