Thanks for the reply.<br>The hangup is literally 5 minutes, CPU is maxed out most of the time. The undo takes 5 seconds, again literally.<br>It doesn't occur in pd-extended.<br><br><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">
Nested gop subpatches should show their outlines and xlets (just like number2 or toggle does as well), shouldn’t they?<br></blockquote><div><br>Well, traditionally they don't and I think they should not. This would be consistent behavior if the borders of every element in the outer GOP subpatch would be visible. *However, I was wrong and actually this is not what's happening.*<br>
</div>Rather, it seems that some GOP subpatches have the wrong size, and then they also show thru nested GOPs. See the attached screenshot: at the top left corder of the open subpatch, there are two GOP subpatches ("Cut" and "Res"; their guts are shown in the open subpatch window), each wider than they should be. The big gray rectangle at the bottom of the image is a large GOP subpatch itself, and the same nested GOP shows thru it. I couldn't reproduce this symptom from scratch.<br>
<br>András<br><br><br><div class="gmail_quote">On Fri, Feb 22, 2013 at 10:37 PM, 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>One clarification now that I read your
report more carefully. Mknob makes abstraction movement slower
because this is the old/non-accelerated pd way of moving things.
The new pd-l2ork model falls back on that when at least one object
in the abstraction does not support accelerated moving. Once I get
to fixing the mknob to support accelerated displace, this will be
fixed. I am still surprised to hear this is taking 5 minutes,
though. Is this an exaggeration or truly 5 minutes?<br>
<br>
Also, if you are undoing objects that are non-accelerated or
complex abstractions, you are running into same problems because
you are moving and redrawing non-accelerated way...<br>
<br>
Is the same slowness perceived on regular pd when moving the said
abstraction?<br> </div></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><div><div><div><br>
<br>
On 02/22/2013 03:34 PM, András Murányi wrote:<br>
</div></div></div>
<blockquote type="cite"><div><div>So, I've played around with the last git, here are
some things I've noticed:<br>
- miXed/toxy is not in pd-l2ork and it's perfectly alrite because
some kinds of [widget] work while others not.<br>
- [flatgui/popup] is installed by default but it throws an error
when clicked on: Invalid command name "pdtk_canvas_mouse".<br>
- moving a simple GOP abstraction with a single [mknob] in it
takes like 5 minutes (!) on a 2.4GHz dual core when the patch is
big. It's fast however when the patch is simple. Undoing the
movement is not instant but it is quick (~5sec).<br>
- nested GOP subpatches show off their outlines and xlets.<br clear="all">
<br>
-- <br>
Murányi András
<br></div></div></blockquote></div></blockquote></div><br>