Re: [PD] stale pointers after object creation (was Re: pix_data issue)

2018-02-28 Thread Jonathan Wilkes via Pd-list 
> a glist (list of graphical objects) is internally implemented as a linked 
> list. usually, a big 

> advantage of a linked lists is that adding/deleting elements won't touch 
> other elements 

> (especially doesn't move them in memory, like it can happen with dynamically 
> sized arrays).

That's the theory.

In practice the insidious audio dropouts happen when Pd is 

*iterating* over a glist, not when adding/deleting objects.

This is because users learn relatively quickly the simple rule 

that adding/deleting objects rebuilds the signal graph, so they 

avoid doing that if at all possible during performance.

However, users generally have no idea what triggers a walk through 

the glist linked list. And those trips can easily cause dropouts 

during a performance-- even merely moving the mouse over a canvas.

So in practice, glist as linked list optimizes for the case not 

often used in realtime performance and is a detriment to performance 

in the cases where it matters (esp. compared to iterating over an 

array, though the number of glist iterations with things like 

mouse motion might trip up audio anyway).

-Jonathan

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] stale pointers after object creation (was Re: pix_data issue)

2018-02-28 Thread Christof Ressi 
I noticed this issue ca. one year ago when I started working on a complex 
project with data structures which involved dynamically adding/deleting objects 
to/from a canvas. I even submitted a bug report: 
https://sourceforge.net/p/pure-data/bugs/1282/

since I've recently started doing a couple a PRs, this is something I want to 
investigate too.

to explain the problem quickly:

a glist (list of graphical objects) is internally implemented as a linked list. 
usually, a big advantage of a linked lists is that adding/deleting elements 
won't touch other elements (especially doesn't move them in memory, like it can 
happen with dynamically sized arrays). I don't see why adding/deleting 
graphical objects should invalidate any gpointers - apart from those which 
pointed to the deleted element(s).

I guess it's meant as a means to keep Pd pointers safe - but what situation 
does it try it prevent?
and why are gpointers also invalidated if you add/delete "normal" text objects 
which are not scalars (and so no gpointer could possibly point to it)?

any pointers (no pun intended) to the reasons behind this desigin decision are 
highly appreciated :-)



> Gesendet: Mittwoch, 28. Februar 2018 um 12:17 Uhr
> Von: Fede 
> An: pd-list@lists.iem.at
> Betreff: [PD] stale pointers after object creation (was Re: pix_data issue)
>
> Ok, so it is a combination of editing the canvas and pointer memory
> 
> i don’t think it has to do with saving.
> also, i don’t think it would relate to the previous pix_data pointer issue
> 
> Here’s a patch
> 
> 
> 
> On Feb 28, 2018, at 11:24 AM, IOhannes m zmölnig  wrote:
> 
> > On 02/28/2018 10:53 AM, Fede Camara Halac wrote:
> >> Would saving (cmd+s) make pix_data forget a pointer, as in [text] or 
> >> [array] objects when using pointers?
> > 
> > that sounds very fishy to.
> > do you have a patch that exposes the forget-on-save behaviour of [array]
> > or [text]?
> > 
> > gfmdasr
> > 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
>

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

[PD] stale pointers after object creation (was Re: pix_data issue)

2018-02-28 Thread Fede 
Ok, so it is a combination of editing the canvas and pointer memory

i don’t think it has to do with saving.
also, i don’t think it would relate to the previous pix_data pointer issue

Here’s a patch




stale-pointer.pd
Description: Binary data

On Feb 28, 2018, at 11:24 AM, IOhannes m zmölnig  wrote:

> On 02/28/2018 10:53 AM, Fede Camara Halac wrote:
>> Would saving (cmd+s) make pix_data forget a pointer, as in [text] or [array] 
>> objects when using pointers?
> 
> that sounds very fishy to.
> do you have a patch that exposes the forget-on-save behaviour of [array]
> or [text]?
> 
> gfmdasr
> 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