> The complexity of the scalars isn't much an issue, more the quantity of elements is what brings tcl/tk down. I think the problem is there, and not really with the Pd core.
 
Tcl/Tk's canvas implementation is just horrible. Whenever you change something in the canvas, it will redraw the whole canvas instead of figuring out what *needs* to be redrawn. Compare this with something like Qt's https://doc.qt.io/qt-5/qgraphicsscene.html which can easily handle thousands of objects by using https://de.wikipedia.org/wiki/Binary_Space_Partitioning. Zooming is also trivial.
 
I've ranted about Tcl/Tk a couple of times, e.g.: https://lists.puredata.info/pipermail/pd-dev/2019-08/022120.html
 
Christof
 
 
Gesendet: Samstag, 04. Januar 2020 um 18:23 Uhr
Von: "João Pais" <jmmmpais@gmail.com>
An: Kein Empfänger
Cc: pd-dev <pd-dev@lists.iem.at>
Betreff: Re: [PD-dev] Fwd: capabilities of data structures with externals
 
(I have here a patch with more than 33548 scalars, and that window does take lots of time to open.)
 
Yeah.. my patch does have some issues locking up PD at this time.. the datastuct is quite complex and if I have the drawing window open when I create the ds then pd hangs for quite a while.. though once I do the initial draw opening and closing the window is quick... I do wish I could have more capabilities for manipulating the visualization without actually changing any data (zoom) which is something that would be pretty trivial with GEM.

The complexity of the scalars isn't much an issue, more the quantity of elements is what brings tcl/tk down. I think the problem is there, and not really with the Pd core.

Zoom is also easy with donecanvasdialog or coords messages, although the speed doesn't change.

It also makes it faster and less prone to bugs to close the canvas while the scalars are being redone, then open it. Vis messages automatize that with no issues.

 

Joao

_______________________________________________ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev