<div class="gmail_quote">On Mon, Mar 4, 2013 at 1:39 AM, Ivica Ico Bukvic <span dir="ltr"><<a 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">
<div bgcolor="#FFFFFF" text="#000000">
<div>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></div></div></blockquote><div><br>That will be cool.<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
<div>
<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></div></div></blockquote><div><br>Yes. It takes much longer in the actual patch where i use it. At least i managed to reproduce the symptom "in vitro",<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><div>
<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></div></div></blockquote><div><br>Yea i know... i need mknob because of its so called "sensibility" option (see mknob-help.pd).<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><div>
<br>
So, what I can do for the next release is add support for
accelerated displacement of mknob and you'll be set.<br></div></div></blockquote><div><br>Thanks a lot in advance!<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><div>
<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></div></div></blockquote><div><br>Those hundreds of subpatches were there for dummy to make the patch big. In real life, i use less. I am interested, however, in other preset saving solutions. I wouldn't lock myself into l2ork at the moment (because it's 0.42) but i'll take a look at the preset_hub thing.<br>
<br>Thanks again Ico!<br><br>András<br></div></div>