Hello list,
I just uploaded a new version of the jmmmp library, with improvements to the [multiarray] object (also at http://bit.ly/jmmmp_056, and soon on deken).
In the help file of [multiarray] I described a problem with the drawing of scalars inside a GOP. Basically, z-order is lost (or changed) when the canvas is redrawn, being it by moving the object, opening the subpatch where it is stored, or minimizing/maximizing the window. You can see all the details in [jmmmp/multtiarray]'s help patch, subpatch [pd SAVE+LOAD]. Does anyone has an explanation for this behavior? Afaik, GOP redrawing works well with other types of objects, but not with scalars.
Best,
Joao
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
On Fri, 2019-09-20 at 12:24 +0200, IOhannes m zmölnig wrote:
adding z-ordering to Pd probably requires a bit of rewriting of the current code...
Personally, I don't see the need for this be tackled in Pd, since one has enough control in the patch to re-order scalars as desired. Rather, I believe dealing with this is best left to the patch author.
OTOH, I wish there was a way to protect (certain) scalars from being touched.
Roman
Personally, I don't see the need for this be tackled in Pd, since one has enough control in the patch to re-order scalars as desired. Rather, I believe dealing with this is best left to the patch author.
There would be two ways of forcing the author to deal with it:
- externally by making it the user's responsability, as indicated in the
example in the patch
- internally by adding a metro with a redrawing command (adding lots of
unnecessary repeating commands to Pd's heaviest member, the gui) Both are a burden either to the user, or to the patch. Garanteing a stable behaviour would be better, instead of shortcuts.
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" zmoelnig@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
On Friday, September 20, 2019, 7:52:07 AM EDT, Christof Ressi christof.ressi@gmx.at wrote:
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.
Scalars in Pd Vanilla don't have a well-defined z-order:
- Display a scalar square on top of a scalar circle2. Delete the scalar circle3. Undo the delete
Now the scalar circle is displayed on top of the scalar square. Pure Data ought to retain the z-ordering in this and other circumstances. If it doesn't please submit a bug and I'll fix it. Best,Jonathan
Am 20. September 2019 13:50:10 MESZ schrieb Christof Ressi christof.ressi@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
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" zmoelnig@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.ressi@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
-
Christof Ressi -
IOhannes m zmölnig -
Jonathan Wilkes -
João Pais -
Roman Haefeli