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@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