[PD] <<Loaded>> event

[Hans-Christoph Steiner]

On Nov 17, 2011, at 6:51 PM, Jonathan Wilkes wrote:

> ----- Original Message -----
> 
>> From: Hans-Christoph Steiner <hans at at.or.at>
>> To: Jonathan Wilkes <jancsika at yahoo.com>
>> Cc: "pd-list at iem.at" <pd-list at iem.at>
>> Sent: Thursday, November 17, 2011 6:20 PM
>> Subject: Re: [PD] <<Loaded>> event
>> 
>> 
>> That's a tricky one.  I think that <<Loaded>> should be sent 
>> when the patch is all done, so the current situation is a bug.
> 
> Ah, ok.
> 
>> Since the 
>> drawing commands come from 'pd', 'pd' would have to trigger the 
>> <<Loaded>> event.  I forget how its triggered now.
> 
> It's triggered in the last line of ::pdtk_canvas::finished_loading_file in 
> pdtk_canvas.tcl.  That proc is called by ::pd_bindings::map in 
> pd_bindings.tcl, where it is preceded by:
> pdsend "$mytoplevel map 1"
> 
> Maybe that line above needs to be the last line of the proc, and when 
> pd is done mapping it should make a call to ::pdtk_canvas::finished_loading_file?  
> I'm still not solid on the back and forth between gui and pd, so I'm not sure 
> if that would help or not.

It'll need to be somewhere else entirely, I think.  "map" is the concept of the window being mapped to the screen.  As you seem to have discovered, the window is mapped to the screen, then pd sends all its draw commands to it.  So ::pdtk_canvas::finished_loading_file should be called once Pd is done sending draw commands.

>> Definitely avoid 'update', I recently refactored my pdwindow.tcl code to 
>> switch from 'update' to 'after idle'.
> 
> I think 'after idle' can also be problematic.

I haven't had any problems so far, and it seems to have improved the performance of the Pd window even more than the update code, though not as drastic a change as the rearchitecting had.

.hc

----------------------------------------------------------------------------

If you are not part of the solution, you are part of the problem.