[PD] GOP Rendering Issue

Ivica Ico Bukvic ico at vt.edu
Thu Jul 7 14:25:51 CEST 2011


On Thu, 2011-07-07 at 08:47 +0200, Ivica Ico Bukvic wrote:
> 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.

I just had a quick look into this issue and it appears that pd-l2ork is
affected as well mainly since coords function was never designed to be
called independently (e.g. via live scripting) as this function is
incomplete in and of itself when it comes to redrawing the object in
question (namely, it does not redraw the object and applies new
xy/margins before calling the redrawing function so that the redrawing
function never sees objects that fall outside the newfound rectangle as
being visible in the first place). I think this is a fundamental problem
with runaway things some users are trying to explore that were never
meant to do what they expect them to. There should be a separate
external API for scripting purposes that ensures that things are done in
the right order/way. As it stands right now there is a "fix" (sort of)
that will make current pd usable with the said coords scripting command
if the following patch is applied to the g_canvas.c. The downside is
that there is yet another redundant redraw of the gop-ed object, which
is not very efficient at all. And while this is not likely to cause
audio dropouts but be aware that this is not something that pd was meant
to do necessarily interactively.

NB: You may have to apply this diff with some level of fuzz since it is
designed to apply cleanly against pd-l2ork trunk rather than
pd-extended. That said, this part of the code should be identical
(AFAIK).

Cheers!

> 
> 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-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 at 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.
> 
> 
> 
> 
> 
> 
> 
> 
_______________________________________________
Pd-list at iem.at mailing list
UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

-------------- next part --------------
A non-text attachment was scrubbed...
Name: g_canvas.c_diff
Type: text/x-patch
Size: 465 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20110707/e5659162/attachment.bin>


More information about the Pd-list mailing list