<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<br>
<blockquote type="cite"
cite="mid:CAOGs2RAGrWyynMVcR337pqBmc=5cdUW9p5G3z+qqy8aBtEdarQ@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div dir="ltr">
<div class="gmail_quote">
<div>(I have here a patch with more than 33548 scalars,
and that window does take lots of time to open.)<br>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>
<div>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.<br>
</div>
</div>
</div>
</div>
</blockquote>
<p>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.<br>
</p>
<p>Zoom is also easy with donecanvasdialog or coords messages,
although the speed doesn't change.</p>
<p>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.</p>
<p><br>
</p>
<p>Joao<br>
</p>
</body>
</html>