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=55...
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 fact 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 moment 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@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-Director Electronic Music Unit
Elder Conservatorium of Music University of Adelaide South Australia 5005
Ph: +61 8 8303 3799 Fax: +61 8 8303 4423 Email: christian.haines@adelaide.edu.au Web: http://emu.adelaide.edu.au http://music.adelaide.edu.au Study: 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.