TBO, I don't see the big difference... What exactly do you mean by that? You're right that the Pd *core* doesn't care about z-order, but drawing commands are sent while traversing the glist, which implies a certain order. The GUI is theoretically not required to draw things in the same order, but it happens to do so and IMO it is the only reasonable behavior with the current implementation (gobjects don't have an explicit z-value).
The point made by Joao is that for regular GUI objects the z-order is stable while for scalars it is not. I would consider this a bug. Christof > Gesendet: Freitag, 20. September 2019 um 20:43 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] > > Am 20. September 2019 13:50:10 MESZ schrieb Christof Ressi > <christof.re...@gmx.at>: > >> 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. > > i think i said "Pd doesn't care about z-ordering at all" rather than "there > is no defined z-ordering in Pd", which is not the same. > > > mfg.hft.fsl > 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
