From canvas_setgraph in g_canvas.c (with my own comments added): if (glist_isvisible(x) && x->gl_goprect) glist_redraw(x); // This ends with a redraw of the GOP window itself on the parent if (x->gl_owner && !x->gl_loading && glist_isvisible(x->gl_owner)) { gobj_vis(&x->gl_gobj, x->gl_owner, 1); // This draws the GOP window for a second time if the above conditional is met canvas_fixlinesfor(x->gl_owner, &x->gl_obj); }
It's a rather innocuous bug since Pd-Vanilla erases the entire graph the moment you draw or update it. But because tk gives you no tools to inspect the data drawn on a tk canvas, it's extremely difficult to track down bugs like these. (I found it with chromium-devtools, which visually highlights graphical elements when you browse them in the html.)
-Jonathan
I believe I put that in because I was unable to figure out how to guarantee things got properly erased in all the strange cases that come up. Now that I'm early in a release cycle maybe I can try to 'fix' this without risking major oopses.
Off to SEAMUS conference for a few days, so this won't happen too fast.
cheers Miller
On Wed, Mar 25, 2015 at 01:31:51AM -0400, Jonathan Wilkes via Pd-list wrote:
From canvas_setgraph in g_canvas.c (with my own comments added): if (glist_isvisible(x) && x->gl_goprect) glist_redraw(x); // This ends with a redraw of the GOP window itself on the parent if (x->gl_owner && !x->gl_loading && glist_isvisible(x->gl_owner)) { gobj_vis(&x->gl_gobj, x->gl_owner, 1); // This draws the GOP window for a second time if the above conditional is met canvas_fixlinesfor(x->gl_owner, &x->gl_obj); }
It's a rather innocuous bug since Pd-Vanilla erases the entire graph the moment you draw or update it. But because tk gives you no tools to inspect the data drawn on a tk canvas, it's extremely difficult to track down bugs like these. (I found it with chromium-devtools, which visually highlights graphical elements when you browse them in the html.)
-Jonathan
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Well, my quick fix was to put an extra gobj_vis call before the current one, and set the flag to "0".
-Jonathan
On Wednesday, March 25, 2015 8:33 PM, Miller Puckette <msp@ucsd.edu> wrote:
I believe I put that in because I was unable to figure out how to guarantee things got properly erased in all the strange cases that come up. Now that I'm early in a release cycle maybe I can try to 'fix' this without risking major oopses.
Off to SEAMUS conference for a few days, so this won't happen too fast.
cheers Miller
On Wed, Mar 25, 2015 at 01:31:51AM -0400, Jonathan Wilkes via Pd-list wrote:
From canvas_setgraph in g_canvas.c (with my own comments added): if (glist_isvisible(x) && x->gl_goprect) glist_redraw(x); // This ends with a redraw of the GOP window itself on the parent if (x->gl_owner && !x->gl_loading && glist_isvisible(x->gl_owner)) { gobj_vis(&x->gl_gobj, x->gl_owner, 1); // This draws the GOP window for a second time if the above conditional is met canvas_fixlinesfor(x->gl_owner, &x->gl_obj); }
It's a rather innocuous bug since Pd-Vanilla erases the entire graph the moment you draw or update it. But because tk gives you no tools to inspect the data drawn on a tk canvas, it's extremely difficult to track down bugs like these. (I found it with chromium-devtools, which visually highlights graphical elements when you browse them in the html.)
-Jonathan
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list