[PD] pd-l2ork feedback

[Ivica Bukvic]

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" <muranyia at gmail.com> 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 <ico at vt.edu> 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
>>
>>
>
> _______________________________________________
> Pd-list at iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20130226/8146e805/attachment.htm>