Attached is the diff for mknob.c to make it "accelerated." Attached is also binary version of mknob.pd_linux (64-bit) (not sure if this one will go through, though).
As for pd-l2ork being 0.42, that is not entirely correct. While elements of GUI are still based on 0.42, many others aren't and pd-l2ork has most if not all patches to the core pd engine inherent to the 0.43 and 0.44 branches, including some that were committed very recently into the sourceforge. It also has a collection of unique patches that don't exist in any of the other versions, so I am not even sure what one would call it other than a pd fork :-)
If you are interested in trying preset_hub and preset_node externals they do come with a fairly comprehensive help file, so hopefully that will help in figuring out how they function.
Best wishes,
Ico
On 03/03/2013 09:27 PM, András Murányi wrote:
On Mon, Mar 4, 2013 at 1:39 AM, Ivica Ico Bukvic <ico@vt.edu mailto:ico@vt.edu> wrote:
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
That will be cool.
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).
Yes. It takes much longer in the actual patch where i use it. At least i managed to reproduce the symptom "in vitro",
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.
Yea i know... i need mknob because of its so called "sensibility" option (see mknob-help.pd).
So, what I can do for the next release is add support for accelerated displacement of mknob and you'll be set.
Thanks a lot in advance!
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.
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.
Thanks again Ico!
András