<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">OK, I checked your patch and now I know
why this is happening. Allow me to explain:<br>
<br>
short (tl;dr) version: once mknob is accelerated (which should be
only a couple of lines of code inside it) this won't be a problem
any more<br>
<br>
For me it takes approx 3 seconds every time I move the gop window
and this solely because mknob is not accelerated (this is on an HP
dm1z AMD APU notebook/netbook).<br>
<br>
long version: What's happening is that pd/extended completely
redraws gop object every time it is moved. What it does not do, is
account for its location (front vs. back) in respect to other
objects when doing this. So, for instance if you move a gop that
is behind another object, once it has been moved, it will appear
in front of it which is wrong since that is not an accurate
reflection where in the gl_list it is located. Hence, next time
your entire canvas redraws (which happens inside pd/extended at
various points), suddenly gop will be again behind the other
object. Confusing, no? Pd-l2ork in an attempt to keep gl_list
consistent always ensures that objects remain visually stacked on
top of each other in the gl_list order no matter what operation
you do. In this case, because we have one of the few remaining gui
objects that do not support accelerated displacement (by
accelerated displacement I mean tagging such object's components
in tcl tk and then moving all objects tagged with the word
"selected" together via a single command rather than redrawing
everything), pd-l2ork falls back to the old pd/extended way of
doing things, just like pd/extended do. It does this with one
notable exception and that is to ensure that the redrawn object
remains stacked where it should be (in terms of front/back) it
also redraws the canvas after such a drag because old way of
redrawing does not account properly for the visual order that
pd-l2ork requires. Since your patch has literally a ton of objects
pertaining to ssssad presets, this takes a while, and hence the
slowness. If you, however, put any iemgui object instead of mknob
inside that gop, the thing will be not only fast, but also much
faster than regular pd/extended.<br>
<br>
So, what I can do for the next release is add support for
accelerated displacement of mknob and you'll be set.<br>
<br>
Another related issue is the redundant use of hundreds of ssssad
abstractions. Pd-l2ork has system-wide preset_hub/preset_node
externals system which is easy to use, supports use in conjunction
with multiple instances of the same abstraction (each is treated
separately and distinctly) as well as many other cool features.
Think of it as pd's counterpart to Max's pattr_storage. Their
implementation is currently possible only in pd-l2ork since it
ensures that all objects remain in the same place in the gl_list
(let's call this gl_list consistency) which is something that
regular pd/extended don't do (as described above). So, long story
short, if you use preset_node and preset_hub you will need only
one of those to replace all of your ssssad abstractions. Pretty
nifty? ;-) And that in near-term will make your canvas redrawing
much faster and consequently a non-issue.<br>
<br>
HTH<br>
<br>
Best wishes,<br>
<br>
Ico<br>
<br>
On 03/03/2013 03:10 PM, András Murányi wrote:<br>
</div>
<blockquote
cite="mid:CAJtGUK48YOMajWX1meomB7uzjCvOt7m6ZJdMcREdk=11CK9tbw@mail.gmail.com"
type="cite">The original patch has many dependencies, however I've
managed to put together a patch which is "big" enough to show the
symptom but has no other dependency than mknob.<br>
Dragging the violet GOP takes quite a few seconds for me, while
dragging the other GOP with the numberbox is fast. The GUI is
unresponsive meanwhile.<br>
Another interesting thing is that when you select a large number
of those [pd presetstore] subpatches and drag them, it really (ok
not really) takes forever. But the bottleneck is not the same
because the GUI stays responsive.<br>
Neither happens in pd-extended.<br>
<br>
Thanks for taking a look!<br>
<br>
András<br>
<br>
<div class="gmail_quote">On Sun, Mar 3, 2013 at 6:47 PM, Ivica
Bukvic <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:ico@vt.edu" target="_blank">ico@vt.edu</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<p dir="ltr">Can you forward patch(es)? Does the abstraction
use any non-default gui objects?</p>
<div class="HOEnZb">
<div class="h5">
<div class="gmail_quote">On Mar 3, 2013 11:34 AM, "András
Murányi" <<a moz-do-not-send="true"
href="mailto:muranyia@gmail.com" target="_blank">muranyia@gmail.com</a>>
wrote:<br type="attribution">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="gmail_quote">On Wed, Feb 27, 2013 at 12:45
AM, Ivica Bukvic <span dir="ltr"><<a
moz-do-not-send="true" href="mailto:ico@vt.edu"
target="_blank">ico@vt.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<p dir="ltr">[...]</p>
<p dir="ltr">Regarding slow redraw, can you try
latest version? I fixed one major inefficiency.</p>
<br>
</blockquote>
<div><br>
I've just compiled the latest git and the slowness
is still there. I have the vague impression
though, that dragging the ominous abstraction got
faster (2 minutes vs previous 5), but again, this
is just an impression.<br>
<br>
András<br>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
<br>
<br clear="all">
<br>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">--
Ivica Ico Bukvic, D.M.A
Composition, Music Technology
Director, DISIS Interactive Sound & Intermedia Studio
Director, L2Ork Linux Laptop Orchestra
Head, ICAT IMPACT Studio
Virginia Tech
Department of Music
Blacksburg, VA 24061-0240
(540) 231-6139
(540) 231-5034 (fax)
disis.music.vt.edu
l2ork.music.vt.edu
ico.bukvic.net</pre>
</body>
</html>