[PD] subtle redrawing bug
jancsika at yahoo.com
Thu Mar 26 18:36:30 CET 2015
Well, my quick fix was to put an extra gobj_vis call before the current one, and set the flag to "0".
On Wednesday, March 25, 2015 8:33 PM, Miller Puckette <msp at 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.
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.)
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Pd-list