On Mon, Mar 4, 2013 at 1:39 AM, Ivica Ico Bukvic <[email protected]> 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
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
