> Pd doesn't care about z-ordering at all and the order of drawing is > mainly defined by "what needs to be done" (rather than: "how will it > look like").
I don't agree that there is no defined z-ordering in Pd, otherwise you couldn't reliably build GUIs. Just imagine that a background canvas would suddenly display in front of a slider. Generally, objects are drawn in the order of creation, it's just that sometimes things get messed up when scalars are involved. Or to quote João: > Afaik, GOP redrawing works well with other types of objects, but not with > scalars. So I also think there is a bug with scalar drawing and I've experienced similar situations (but didn't have to patience to narrow it down). Christof > Gesendet: Freitag, 20. September 2019 um 12:24 Uhr > Von: "IOhannes m zmölnig" <zmoel...@iem.at> > An: pd-list@lists.iem.at > Betreff: Re: [PD] GOP drawing bug with scalars and z-order - test in > [jmmmp/multiarray] > > On 9/20/19 11:26 AM, João Pais wrote: > > z-order is lost (or changed) > > z-ordering is based on the order of drawing commands (things drawn later > will paint on top of what is already there). > Pd doesn't care about z-ordering at all and the order of drawing is > mainly defined by "what needs to be done" (rather than: "how will it > look like"). > > adding z-ordering to Pd probably requires a bit of rewriting of the > current code... > > gamdsr > IOhannes > > > _______________________________________________ > Pd-list@lists.iem.at mailing list > UNSUBSCRIBE and account-management -> > https://lists.puredata.info/listinfo/pd-list > _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
