This may be because you didn't hide gop titles, in which case pd-l2ork resizes gop size to match the text width.
Regarding slow redraw, can you try latest version? I fixed one major inefficiency. On Feb 26, 2013 6:22 PM, "András Murányi" <[email protected]> wrote: > Thanks for the reply. > The hangup is literally 5 minutes, CPU is maxed out most of the time. The > undo takes 5 seconds, again literally. > It doesn't occur in pd-extended. > > Nested gop subpatches should show their outlines and xlets (just like >> number2 or toggle does as well), shouldn’t they? >> > > 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.* > 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. > > András > > > On Fri, Feb 22, 2013 at 10:37 PM, Ivica Ico Bukvic <[email protected]> wrote: > >> 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? >> >> 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... >> >> Is the same slowness perceived on regular pd when moving the said >> abstraction? >> >> > >> >> On 02/22/2013 03:34 PM, András Murányi wrote: >> >> So, I've played around with the last git, here are some things I've >> noticed: >> - miXed/toxy is not in pd-l2ork and it's perfectly alrite because some >> kinds of [widget] work while others not. >> - [flatgui/popup] is installed by default but it throws an error when >> clicked on: Invalid command name "pdtk_canvas_mouse". >> - 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). >> - nested GOP subpatches show off their outlines and xlets. >> >> -- >> Murányi András >> >> > > _______________________________________________ > [email protected] mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > >
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
