Hey all
Following up a thread from 2011: https://lists.puredata.info/pipermail/pd-list/2011-04/088306.html
I would like to know whether it is impossible to delete a specific scalar, by pointer. If so, why is that? Does it use a design that makes it difficult to allow this? To my untrained eye there is no apparent reason why it is possible by editing the GUI graphically/manually, but not per message.
Roman
Hi Roman,
to my knowledge it is not possible to delete a single scalar. The method to get rid of a scalar is to clear the subpatch and recreate everything.
best wishes, ingo
On 05/18/2018 11:36 PM, Roman Haefeli wrote:
Hey all
Following up a thread from 2011: https://lists.puredata.info/pipermail/pd-list/2011-04/088306.html
I would like to know whether it is impossible to delete a specific scalar, by pointer. If so, why is that? Does it use a design that makes it difficult to allow this? To my untrained eye there is no apparent reason why it is possible by editing the GUI graphically/manually, but not per message.
Roman
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On Sat, 2018-05-19 at 00:02 +0200, Ingo Stock wrote:
to my knowledge it is not possible to delete a single scalar.
Thanks for the confirmation. I'm also wondering whether this will always be like this or if it would be a trivial feature to add.
The method to get rid of a scalar is to clear the subpatch and recreate everything.
Yeah. It's not very elegant and gets expensive pretty quickly. I was wondering about alternative strategies, like moving non-used scalars out-of-the-way and later re-use them. It's cumbersome to implement, but probably less drastic than the clear-all-and-rebuild method. My goal is to build GUIs with ds that are fully functional without requiring switching into edit mode. I'd be interested in hearing about similar success (or failure) stories.
Roman
On 05/18/2018 11:36 PM, Roman Haefeli wrote:
Hey all
Following up a thread from 2011: https://lists.puredata.info/pipermail/pd-list/2011-04/088306.html
I would like to know whether it is impossible to delete a specific scalar, by pointer. If so, why is that? Does it use a design that makes it difficult to allow this? To my untrained eye there is no apparent reason why it is possible by editing the GUI graphically/manually, but not per message.
Roman
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/l istinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/lis tinfo/pd-list
On 05/19/2018 11:56 AM, Roman Haefeli wrote:
Yeah. It's not very elegant and gets expensive pretty quickly. I was wondering about alternative strategies, like moving non-used scalars out-of-the-way and later re-use them. It's cumbersome to implement, but probably less drastic than the clear-all-and-rebuild method.
Can only answer to this: There are several methods to make scalars invisible. Anyhow, in my experience the method to clear the subpatch and recreate everything works quite well and is imho the clean approach to do it, as all the scalars are redrawn every frame any way.
There are other limits to the use of data structures. Depending on your computer, when you get above 800 scalars or so, the patch becomes laggy.
Consider the attached patch: On load 1050 scalars are created, which is already quite heavy on my computer. Anyhow, deleting a scalar by clicking on it works fine, using the clear and redraw method.
Hiding scalars by making them invisible doesn't help with the lagging problem. Therefore i would recommend the clear and redraw method any day. ;)
best wishes, ingo
On Sat, 2018-05-19 at 17:00 +0200, Ingo Stock wrote:
On 05/19/2018 11:56 AM, Roman Haefeli wrote:
Yeah. It's not very elegant and gets expensive pretty quickly. I was wondering about alternative strategies, like moving non-used scalars out-of-the-way and later re-use them. It's cumbersome to implement, but probably less drastic than the clear-all-and-rebuild method.
Can only answer to this: There are several methods to make scalars invisible. Anyhow, in my experience the method to clear the subpatch and recreate everything works quite well and is imho the clean approach to do it, as all the scalars are redrawn every frame any way.
There are other limits to the use of data structures. Depending on your computer, when you get above 800 scalars or so, the patch becomes laggy.
Thanks for your considerations. That is exactly the kind of info that I was looking for. I don't share the experience with the limit of 800, though, but this is presumably related to the computer/CPU.
Consider the attached patch:
Nice and illustrative example patch.
On load 1050 scalars are created, which is already quite heavy on my computer.
I'm not sure I understand correctly. Just having the patch open is heavy on your box? Or interacting with it?
Anyhow, deleting a scalar by clicking on it works fine, using the clear and redraw method.>>
It works fine for me, too. Then I measured the time it takes to redraw different numbers of squares. It seems computation time is roughly proportional to the number of redrawn objects (1: 0.08ms, 500: 3.9ms, 1000: 7.6ms). So there is a penalty of this method with larger numbers of scalars.
Hiding scalars by making them invisible doesn't help with the lagging problem. Therefore i would recommend the clear and redraw method any day. ;)
I don't experience any lags by making specific scalars invisible. It takes 0.007ms to make a single scalar invisible within a subpatch of 1050 squares. See my modified version of your patch.
Roman
Thanks for your testing!
The lag appears on my computer already with the patch i sent with the 1050 scalars. It shows when i open the patch, create any object, say a [float] and try to move it around.
With more scalars it can become even worse. You can test it with the attached patch. First select width and height and then click create. It creates a rectangle made of width x height one-pixel-scalars.
With about 100 x 100 pixel, clearing the patch becomes increasingly slow. With 640 x 256 pixel, it took more than nine minutes on my computer to clear the subpatch or even to close the window, so be warned! ;)
The reason for the lag is afaik, that all interface objects are constantly redrawn by Tcl, so it is not limited to scalars.
best, ingo
On 05/19/2018 11:23 PM, Roman Haefeli wrote:
On Sat, 2018-05-19 at 17:00 +0200, Ingo Stock wrote:
On 05/19/2018 11:56 AM, Roman Haefeli wrote:
Yeah. It's not very elegant and gets expensive pretty quickly. I was wondering about alternative strategies, like moving non-used scalars out-of-the-way and later re-use them. It's cumbersome to implement, but probably less drastic than the clear-all-and-rebuild method.
Can only answer to this: There are several methods to make scalars invisible. Anyhow, in my experience the method to clear the subpatch and recreate everything works quite well and is imho the clean approach to do it, as all the scalars are redrawn every frame any way.
There are other limits to the use of data structures. Depending on your computer, when you get above 800 scalars or so, the patch becomes laggy.
Thanks for your considerations. That is exactly the kind of info that I was looking for. I don't share the experience with the limit of 800, though, but this is presumably related to the computer/CPU.
Consider the attached patch:
Nice and illustrative example patch.
On load 1050 scalars are created, which is already quite heavy on my computer.
I'm not sure I understand correctly. Just having the patch open is heavy on your box? Or interacting with it?
Anyhow, deleting a scalar by clicking on it works fine, using the clear and redraw method.>>
It works fine for me, too. Then I measured the time it takes to redraw different numbers of squares. It seems computation time is roughly proportional to the number of redrawn objects (1: 0.08ms, 500: 3.9ms, 1000: 7.6ms). So there is a penalty of this method with larger numbers of scalars.
Hiding scalars by making them invisible doesn't help with the lagging problem. Therefore i would recommend the clear and redraw method any day. ;)
I don't experience any lags by making specific scalars invisible. It takes 0.007ms to make a single scalar invisible within a subpatch of 1050 squares. See my modified version of your patch.
Roman
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
as I recall, in a mail Miller said that it wasn't easy to implement a
"delete" (or "previous" etc.) methods, because it would mix up the pointer
structures. But most likely I'm remembering incorrectly.
The lag with scalars is a real thing, as with any other canvas with lots
of gui objects running in tcl/tk - including that in scalars you have
extra lag if you move the mouse over them, even without clicking.
Switching off the mouse detection on demand would make things faster.
I have a patch with more than 33548 scalars, and it takes several minutes
to open in my desktop; on my laptop, it just stays there with cpu at 100%
without opening.
Best,
Joao
Thanks for your testing!
The lag appears on my computer already with the patch i sent with the 1050 scalars. It shows when i open the patch, create any object, say a [float] and try to move it around.
With more scalars it can become even worse. You can test it with the attached patch. First select width and height and then click create. It creates a rectangle made of width x height one-pixel-scalars.
With about 100 x 100 pixel, clearing the patch becomes increasingly slow. With 640 x 256 pixel, it took more than nine minutes on my computer to clear the subpatch or even to close the window, so be
warned! ;)The reason for the lag is afaik, that all interface objects are constantly redrawn by Tcl, so it is not limited to scalars.
best, ingo
On 05/19/2018 11:23 PM, Roman Haefeli wrote:
On Sat, 2018-05-19 at 17:00 +0200, Ingo Stock wrote:
On 05/19/2018 11:56 AM, Roman Haefeli wrote:
Yeah. It's not very elegant and gets expensive pretty quickly. I was wondering about alternative strategies, like moving non-used scalars out-of-the-way and later re-use them. It's cumbersome to implement, but probably less drastic than the clear-all-and-rebuild method.
Can only answer to this: There are several methods to make scalars invisible. Anyhow, in my experience the method to clear the subpatch and recreate everything works quite well and is imho the clean approach to do it, as all the scalars are redrawn every frame any way.
There are other limits to the use of data structures. Depending on your computer, when you get above 800 scalars or so, the patch becomes laggy.
Thanks for your considerations. That is exactly the kind of info that I was looking for. I don't share the experience with the limit of 800, though, but this is presumably related to the computer/CPU.
Consider the attached patch:
Nice and illustrative example patch.
On load 1050 scalars are created, which is already quite heavy on my computer.
I'm not sure I understand correctly. Just having the patch open is heavy on your box? Or interacting with it?
Anyhow, deleting a scalar by clicking on it works fine, using the clear and redraw method.>>
It works fine for me, too. Then I measured the time it takes to redraw different numbers of squares. It seems computation time is roughly proportional to the number of redrawn objects (1: 0.08ms, 500: 3.9ms, 1000: 7.6ms). So there is a penalty of this method with larger numbers of scalars.
Hiding scalars by making them invisible doesn't help with the lagging problem. Therefore i would recommend the clear and redraw method any day. ;)
I don't experience any lags by making specific scalars invisible. It takes 0.007ms to make a single scalar invisible within a subpatch of 1050 squares. See my modified version of your patch.
Roman
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list
Just thought of this after sending the previous mail. I can't try this
hack, but it might work. To delete a scalar:
- get the scalar's x/y coordinates
- use mouse messages to select and delete anything over that pixel.
Drawbacks:
- will delete anything else over that pixel (affects the selectable area
of any scalar)
- the canvas will need to be traversed again before getting a pointer (as
the scalar list will need to be redone)
It might work, but only under certain circumstances.
Joao
as I recall, in a mail Miller said that it wasn't easy to implement a
"delete" (or "previous" etc.) methods, because it would mix up the
pointer structures. But most likely I'm remembering incorrectly.The lag with scalars is a real thing, as with any other canvas with lots
of gui objects running in tcl/tk - including that in scalars you have
extra lag if you move the mouse over them, even without clicking.
Switching off the mouse detection on demand would make things faster.I have a patch with more than 33548 scalars, and it takes several
minutes to open in my desktop; on my laptop, it just stays there with
cpu at 100% without opening.Best,
Joao
Thanks for your testing!
The lag appears on my computer already with the patch i sent with the 1050 scalars. It shows when i open the patch, create any object, say a [float] and try to move it around.
With more scalars it can become even worse. You can test it with the attached patch. First select width and height and then click create. It creates a rectangle made of width x height one-pixel-scalars.
With about 100 x 100 pixel, clearing the patch becomes increasingly slow. With 640 x 256 pixel, it took more than nine minutes on my computer to clear the subpatch or even to close the window, so be
warned! ;)The reason for the lag is afaik, that all interface objects are constantly redrawn by Tcl, so it is not limited to scalars.
best, ingo
On 05/19/2018 11:23 PM, Roman Haefeli wrote:
On Sat, 2018-05-19 at 17:00 +0200, Ingo Stock wrote:
On 05/19/2018 11:56 AM, Roman Haefeli wrote:
Yeah. It's not very elegant and gets expensive pretty quickly. I was wondering about alternative strategies, like moving non-used scalars out-of-the-way and later re-use them. It's cumbersome to implement, but probably less drastic than the clear-all-and-rebuild method.
Can only answer to this: There are several methods to make scalars invisible. Anyhow, in my experience the method to clear the subpatch and recreate everything works quite well and is imho the clean approach to do it, as all the scalars are redrawn every frame any way.
There are other limits to the use of data structures. Depending on your computer, when you get above 800 scalars or so, the patch becomes laggy.
Thanks for your considerations. That is exactly the kind of info that I was looking for. I don't share the experience with the limit of 800, though, but this is presumably related to the computer/CPU.
Consider the attached patch:
Nice and illustrative example patch.
On load 1050 scalars are created, which is already quite heavy on my computer.
I'm not sure I understand correctly. Just having the patch open is heavy on your box? Or interacting with it?
Anyhow, deleting a scalar by clicking on it works fine, using the clear and redraw method.>>
It works fine for me, too. Then I measured the time it takes to redraw different numbers of squares. It seems computation time is roughly proportional to the number of redrawn objects (1: 0.08ms, 500: 3.9ms, 1000: 7.6ms). So there is a penalty of this method with larger numbers of scalars.
Hiding scalars by making them invisible doesn't help with the lagging problem. Therefore i would recommend the clear and redraw method any day. ;)
I don't experience any lags by making specific scalars invisible. It takes 0.007ms to make a single scalar invisible within a subpatch of 1050 squares. See my modified version of your patch.
Roman
that's the hack I've described in link provided by Derek :-)
I think there a two major issues with Pd's GUI:
- the Tk canvas (I believe) doesn't offer any kind of spatial partitioning, so it has to check each item if it's visible (or maybe just draws all of them). OTOH, Qt offers the QGraphicsScene framework which lets you work with thousands of objects quite efficiently (I recently used it for a tile map editor and it works really well)
- the collision detection is done in the Pd core, so for every mouse interaction the whole glist has to be traversed until the right object is found. Pd could use a different data structure to group the objects by position but I don't know if it would be worth the effort.
I think the long term goal is to have a completely generic GUI interface and let a decent GUI framework handle all the complexity, but the developer willing to implement this is yet to be found...
that being said, the Pd GUI works well enough for me most of the time. if it doesn't, it probably means it's not the right tool for the job and something like PyQt will be the better choice. how does the saying go: "If your only tool is a hammer then every problem looks like a nail".
Gesendet: Sonntag, 20. Mai 2018 um 15:44 Uhr Von: "João Pais" jmmmpais@gmail.com An: pd-list@lists.iem.at, "Ingo Stock" mail@ingostock.de Betreff: Re: [PD] Data structures - delete specific scalar?
Just thought of this after sending the previous mail. I can't try this
hack, but it might work. To delete a scalar:
- get the scalar's x/y coordinates
- use mouse messages to select and delete anything over that pixel.
Drawbacks:
- will delete anything else over that pixel (affects the selectable area
of any scalar)
- the canvas will need to be traversed again before getting a pointer (as
the scalar list will need to be redone)
It might work, but only under certain circumstances.
Joao
as I recall, in a mail Miller said that it wasn't easy to implement a
"delete" (or "previous" etc.) methods, because it would mix up the
pointer structures. But most likely I'm remembering incorrectly.The lag with scalars is a real thing, as with any other canvas with lots
of gui objects running in tcl/tk - including that in scalars you have
extra lag if you move the mouse over them, even without clicking.
Switching off the mouse detection on demand would make things faster.I have a patch with more than 33548 scalars, and it takes several
minutes to open in my desktop; on my laptop, it just stays there with
cpu at 100% without opening.Best,
Joao
Thanks for your testing!
The lag appears on my computer already with the patch i sent with the 1050 scalars. It shows when i open the patch, create any object, say a [float] and try to move it around.
With more scalars it can become even worse. You can test it with the attached patch. First select width and height and then click create. It creates a rectangle made of width x height one-pixel-scalars.
With about 100 x 100 pixel, clearing the patch becomes increasingly slow. With 640 x 256 pixel, it took more than nine minutes on my computer to clear the subpatch or even to close the window, so be
warned! ;)The reason for the lag is afaik, that all interface objects are constantly redrawn by Tcl, so it is not limited to scalars.
best, ingo
On 05/19/2018 11:23 PM, Roman Haefeli wrote:
On Sat, 2018-05-19 at 17:00 +0200, Ingo Stock wrote:
On 05/19/2018 11:56 AM, Roman Haefeli wrote:
Yeah. It's not very elegant and gets expensive pretty quickly. I was wondering about alternative strategies, like moving non-used scalars out-of-the-way and later re-use them. It's cumbersome to implement, but probably less drastic than the clear-all-and-rebuild method.
Can only answer to this: There are several methods to make scalars invisible. Anyhow, in my experience the method to clear the subpatch and recreate everything works quite well and is imho the clean approach to do it, as all the scalars are redrawn every frame any way.
There are other limits to the use of data structures. Depending on your computer, when you get above 800 scalars or so, the patch becomes laggy.
Thanks for your considerations. That is exactly the kind of info that I was looking for. I don't share the experience with the limit of 800, though, but this is presumably related to the computer/CPU.
Consider the attached patch:
Nice and illustrative example patch.
On load 1050 scalars are created, which is already quite heavy on my computer.
I'm not sure I understand correctly. Just having the patch open is heavy on your box? Or interacting with it?
Anyhow, deleting a scalar by clicking on it works fine, using the clear and redraw method.>>
It works fine for me, too. Then I measured the time it takes to redraw different numbers of squares. It seems computation time is roughly proportional to the number of redrawn objects (1: 0.08ms, 500: 3.9ms, 1000: 7.6ms). So there is a penalty of this method with larger numbers of scalars.
Hiding scalars by making them invisible doesn't help with the lagging problem. Therefore i would recommend the clear and redraw method any day. ;)
I don't experience any lags by making specific scalars invisible. It takes 0.007ms to make a single scalar invisible within a subpatch of 1050 squares. See my modified version of your patch.
Roman
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
2018-05-19 6:56 GMT-03:00 Roman Haefeli reduzent@gmail.com:
On Sat, 2018-05-19 at 00:02 +0200, Ingo Stock wrote:
to my knowledge it is not possible to delete a single scalar.
Thanks for the confirmation. I'm also wondering whether this will always be like this or if it would be a trivial feature to add.
I can't see why it has to stay like this, I'd move past that and ask how we could implement it, then try to work on a pull request :)
Roman Haefeli reduzent@gmail.com writes:
Hey all
Following up a thread from 2011: https://lists.puredata.info/pipermail/pd-list/2011-04/088306.html
I would like to know whether it is impossible to delete a specific scalar, by pointer. If so, why is that? Does it use a design that makes it difficult to allow this? To my untrained eye there is no apparent reason why it is possible by editing the GUI graphically/manually, but not per message.
Roman _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
If I'm not mistaken, this relates to a thread I started in Jan 2017 and I think this bit from Christof Ressi might prove releavant to these discussions so hopefully this link could help with the current discussion:
https://lists.puredata.info/pipermail/pd-list/2017-01/117295.html
Derek
On Sun, 2018-05-20 at 05:40 -0700, Derek Kwan wrote:
Roman Haefeli reduzent@gmail.com writes:
Hey all
Following up a thread from 2011: https://lists.puredata.info/pipermail/pd-list/2011-04/088306.html
If I'm not mistaken, this relates to a thread I started in Jan 2017 and I think this bit from Christof Ressi might prove releavant to these discussions so hopefully this link could help with the current discussion:
https://lists.puredata.info/pipermail/pd-list/2017-01/117295.html
Oh yes. I didn't find this one when using search machines. This basically answers my questions. Thanks.
Roman
-
Alexandre Torres Porres -
Christof Ressi -
Derek Kwan -
Ingo Stock -
João Pais -
Roman Haefeli