[PD] pd-l2ork feedback

[Ivica Ico Bukvic]

OK, I checked your patch and now I know why this is happening. Allow me 
to explain:

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

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).

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.

So, what I can do for the next release is add support for accelerated 
displacement of mknob and you'll be set.

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.

HTH

Best wishes,

Ico

On 03/03/2013 03:10 PM, András Murányi wrote:
> 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.
> 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.
> 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.
> Neither happens in pd-extended.
>
> Thanks for taking a look!
>
> András
>
> On Sun, Mar 3, 2013 at 6:47 PM, Ivica Bukvic <ico at vt.edu 
> <mailto:ico at vt.edu>> wrote:
>
>     Can you forward patch(es)? Does the abstraction use any
>     non-default gui objects?
>
>     On Mar 3, 2013 11:34 AM, "András Murányi" <muranyia at gmail.com
>     <mailto:muranyia at gmail.com>> wrote:
>
>         On Wed, Feb 27, 2013 at 12:45 AM, Ivica Bukvic <ico at vt.edu
>         <mailto:ico at vt.edu>> wrote:
>
>             [...]
>
>             Regarding slow redraw, can you try latest version? I fixed
>             one major inefficiency.
>
>
>
>         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.
>
>         András
>
>
>
>


-- 
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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20130303/7277a6f7/attachment-0001.htm>