[PD] GOP Rendering Issue

Jonathan Wilkes jancsika at yahoo.com
Thu Jul 7 18:32:12 CEST 2011


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).

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"

-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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20110707/b73d2e51/attachment-0001.htm>


More information about the Pd-list mailing list