Well, I tried to fix this but can't figure out how yet. The commit a356e00da4 seems to be necessary to address the problem in issue #2758 (sorry, I can't figure out how to make these citations look like links as the rest of you seem to be able to :) But that PR redraws the entire owning window - and if you've got 100s of objects getting resized this makes 100s of redraws. There should probably be a way to defer these redraws (as there is for dragging as in delay_move() ) but this could create all sorts of subtle problems with objects getting deleted and then modified afterward.
I also tried replacing the redraw (commented as "redraw parent to remove "ghost objects") with gobj_vis(..., 0) and gobj_vis(..., 1) but that somehow did nothing. So unless someone can come up with a better fix I think we should just leave this and try to improve it for 0.57.
here's a smaller patch that I'm fighting with:
#N canvas 374 278 777 417 12; #N canvas 850 145 788 454 $0-goprect 0; #X text 182 12 comment1; #X text 128 37 comment2; #X obj 19 284 outlet; #X obj 73 284 outlet; #X obj 261 222 s pd-$0-goprect; #X obj 261 122 tgl 19 0 empty empty empty 0 -10 0 12 #fcfcfc #000000 #000000 0 1 ; #X obj 261 146 * 100; #X obj 261 170 + 100; #X msg 261 195 goprect 10 10 $1 50; #X obj 370 81 tgl 19 0 empty empty empty 0 -10 0 12 #fcfcfc #000000 #000000 0 1; #X obj 370 105 * 100, f 6; #X obj 370 129 + 100; #X msg 370 153 donecanvasdialog 1 -1 1 0 -1 1 1 $1 50 10 10; #X obj 474 40 tgl 19 0 empty empty empty 0 -10 0 12 #fcfcfc #000000 #000000 0 1; #X obj 474 64 * 100, f 6; #X obj 474 88 + 100; #X msg 474 112 coords 0 -1 1 1 $1 50 1 10 10; #X floatatom 131 18 5 0 0 0 - - - 0; #X connect 5 0 6 0; #X connect 6 0 7 0; #X connect 7 0 8 0; #X connect 8 0 4 0; #X connect 9 0 10 0; #X connect 10 0 11 0; #X connect 11 0 12 0; #X connect 12 0 4 0; #X connect 13 0 14 0; #X connect 14 0 15 0; #X connect 15 0 16 0; #X connect 16 0 4 0; #X coords 0 -1 1 1 100 50 1 10 10; #X restore 53 51 pd $0-goprect; #X obj 424 188 s pd-$0-goprect; #X obj 53 205 f; #X obj 430 80 tgl 19 0 empty empty empty 0 -10 0 12 #fcfcfc #000000 #000000 0 1; #X obj 430 104 * 100, f 6; #X obj 430 128 + 100; #X msg 431 151 coords 0 -1 1 1 $1 50 1 10 10; #X connect 0 0 2 0; #X connect 0 1 2 1; #X connect 3 0 4 0; #X connect 4 0 5 0; #X connect 5 0 6 0; #X connect 6 0 1 0;
On 11/4/25 9:27 AM, Roman Haefeli wrote:
On Sun, 2025-11-02 at 21:31 +0100, Roman Haefeli wrote:
On Fri, 2025-10-31 at 10:58 +0100, Miller Puckette via Pd-dev wrote:
OK... I've merged 1 of the two commits (e47c2d517) so far which I hope fixes things - the second commit seems to be an improvement but not crucial (and I really want to get 0.56-2 out to fix a couple of crasher bugs)
Let me know if there's actually an urgent need for that second commit (a356e00da4)
I'm not really sure. Things have improved twice with recent commits. With master of the time of your mail, ghost objects were gone. But interactive GOPs using 'coords' felt a bit sluggish. Now, with current master (09598037) 'coords' updates happen quickly. I can't spot any regressions compared to 0.56-0.
Some GUI updates are really slow now. The lag seems proportional to the number of GOP abstraction in the canvas. Maybe this is related to redrawing the parent on certain actions? Anyway, I tried to capture the difference in screencasts that compare 0.56-0 (quick) to current master (slow):
https://netpd.org/~roman/tmp/gop-performance/
It seems that in 0.56-0 updating a GOP is not affected by the amount of other GOPs on the canvas (or it is so quick that I don't notice it).
Roman
pd-dev@lists.iem.at - the Pd developers' mailinglist https://lists.iem.at/hyperkitty/list/pd-dev@lists.iem.at/message/WNOJ6FNESEY...