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 <[email protected]> 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 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 _______________________________________________ [email protected] 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: [email protected] 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.
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
