[PD] GOP Rendering Issue

[Ivica Ico Bukvic]

Jonathan Wilkes <jancsika at yahoo.com> wrote:

>I tested the patch from
>http://sourceforge.net/tracker/?func=detail&aid=3030159&group_id=55736&atid=478070
>with pd-l2ork (Pd version 0.42.5-extended-l2ork-20110427)
>and every time I clicked the tgl in the parent patch it put me into
>edit mode. (Doesn't 
>do that in pd vanilla).

Thanks for the report. Allow me to investigate.

>
>Also, selecting and deselecting the tgl when it has a label gives an
>error to the terminal 
>from which I'm running pd-l2ork:
>unknown option "-fill"

I have seen this before and I traced it down to tcl/tk. The command is in iemgui objects to allow for global custom colors. The irony is tcltk interprets the flag correctly and online documentation suggests this is a valid flag for the said widget but for some reason it keeps triggering those errors in the console.

>
>-Jonathan
>
>
>--- On Thu, 7/7/11, Ivica Ico Bukvic <ico at vt.edu> wrote:
>
>From: Ivica Ico Bukvic <ico at vt.edu>
>Subject: Re: [PD] GOP Rendering Issue
>To: "Christian Haines" <christian.haines at adelaide.edu.au>,
>Pd-list at iem.at
>Date: Thursday, July 7, 2011, 8:47 AM
>
>Neither if those are fixes but rather hacks that should be avoided
>because once the bug is fixed you will have to go back and change all
>your existing patches with this workaround. Pd already redraws entire
>gop object every time you move it or change its properties. I think
>this is because of out-of-order redrawing bug that persists in pd (at
>least it did since last time I checked). If you can please send a
>simplified version of the actual patch to test it in the l2ork
>iteration of pd which has afaik all known gop issues fixed, that could
>shed some light where the problem lies.
>
>
>
>Ivica Ico Bukvic, D.M.A
>
>Composition, Music Technology
>
>Director, DISIS Interactive Sound & Intermedia Studio
>
>Director, L2Ork LinuxLaptop Orchestra
>
>Assistant Co-Director, CCTAD
>
>CHCI, CS, and Art (by courtesy)
>
>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
>
>Christian Haines <christian.haines at adelaide.edu.au> wrote:
>Thanks. I have added a comment to that bug report. 
>I note somewhere else on the list suggested using a kind of 'whiteout'
>approach by moving a white canvas over the the offending items prior to
>resizing - after resizing the canvas 'looks' ok. In short, visually
>this solves the issue, but if you do this overlapping other objects /
>GOPs etc then they suffer from the rendering issue by getting whited
>out. 
>That's part of the workaround.
>
>To resolve the issue completely (at least visually) I have a receive
>object in each GOP abstraction which acts as a global message bus to
>all GOPs. This bus is connected to a namecanvas send and sends a vis 0
>and vis 1 message to turn the (and each and every) GOP's visibility
>on/off. 
>There is probably a more elegant solution .. which I'll post when/if I
>figure it.
>Best
>On 06/07/2011, at 12:!
> 22 PM,
>Hans-Christoph Steiner wrote:
>
>Hey Christian
>Thanks for the thorough bug report, the video is great.  I think that's
>a known bug, or at least it seems familiar to me.  It would be great to
>have this info in the bug tracker so we can keep track of it.  This bug
>seems similar:
>https://sourceforge.net/tracker/?func=detail&aid=3030159&group_id=55736&atid=478070
>If that's not it, then feel free to create a new bug report in the
>tracker.
>.hc
>On Jun 28, 2011, at 10:51 PM, Christian Haines wrote:
>
>
>Hi All
>I have created an GOP abstraction which I include in a parent parent.
>The GOP interface has a button that resizes it by sending a 'coords'
>message to the GOP abstraction canvas (namecanvas named). When it
>resizes larger it renders the larger interface properly over the
>patch's white background. However, when it resizes smaller it leaves a
>remnant of the larger interface visible. Sometimes to correctly show
>the smaller interface, I have to redraw / refresh the window by moving
>the window - this doesn't always work though. In fa!
> ct it
>only works when the parent patch has a '#coords' line with a specific
>configuration in it - of which I'm not sure.  I'm on OSX. I've seen the
>issue documented elsewhere but never read a full description on how to
>resolve it fully.
>See the issue here: http://echoblue.com.au/pd/goprenderissue.mov
>
>At the mo!
> ment I
>am sending a message back to the parent patch from the GOP abstraction
>to change the parent patch's 'setbounds' by 1 pixel and then move it
>back - this resolves that issue but, as mentioned, not consistently.
>Regardless, it creates two more issues: (1) setbounds behaves oddly -
>doesn't resize until a close and reopen; and/or moves the objects in
>the patch window without resizing; (2) I can't know the patch window
>size dynamically (say by querying the canvas) hence any size change by
>setbounds is not necessarily the same as the original window size (if
>it was resizing!).
>Any suggestions would be greatly appreciated
> 
>
>--Christian
>  
>_______________________________________________
>Pd-list at iem.at mailing list
>UNSUBSCRIBE and account-management ->
>http://lists.puredata.info/listinfo/pd-list
>
> 
>
>----------------------------------------------------------------------------
>Terrorism is not an enemy.  It cannot be defeated.  It's a
>tactic.  It's about as sensible to say!
>  we
>declare war on night attacks and expect we're going to win that
>war.  We're not going to win the war on terrorism.        - retired
>U.S. Army general, William Odom
> 
>
>
>--Christian Haines
>Lecturer / Co-DirectorElectronic Music Unit
>Elder Conservatorium of MusicUniversity of AdelaideSouth Australia
> 5005
>Ph: +61 8 8303 3799Fax: +61 8 8303 4423Email:
>christian.haines at adelaide.edu.auWeb: http://emu.adelaide.edu.au        
> http://music.adelaide.edu.auStudy:
>http://emu.adelaide.edu.au/study/Location: Schulz Building, Level 5 ,
>5.13
>
>-----------------------------------------------------------CRICOS
>Provider Number
>00123M-----------------------------------------------------------This
>email message is intended only for the addressee(s) and contains
>information that may be confidential and/or copyright. If you are not
>the intended recipient please notify the sender by reply email and
>immediately delete this email. Use, disclosure or reproduction of this
>email by anyone other than the intended recipient(s) is strictly
>prohibited. No representation is made that this email or any
>attachments are free of viruses. Virus scanning is recommended and is
>the responsibility of the recipient.
>
>
>
>
>
>
>
>-----Inline Attachment Follows-----
>
>_______________________________________________
>Pd-list at iem.at mailing list
>UNSUBSCRIBE and account-management ->
>http://lists.puredata.info/listinfo/pd-list


Ivica Ico Bukvic, D.M.A
Composition, Music Technology
Director, DISIS Interactive Sound & Intermedia Studio
Director, L2Ork LinuxLaptop Orchestra
Assistant Co-Director, CCTAD
CHCI, CS, and Art (by courtesy)
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