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 <i...@vt.edu
<mailto:i...@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" <muran...@gmail.com
<mailto:muran...@gmail.com>> wrote:
On Wed, Feb 27, 2013 at 12:45 AM, Ivica Bukvic <i...@vt.edu
<mailto:i...@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
_______________________________________________
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
