[PD] More pdp blues

Yves Degoyon ydegoyon at free.fr
Sat May 8 04:25:24 CEST 2004


nice patch )

well, this patch revealed a bug in the pdp_canvas object,
the packets were not internally freed
and that led to huge memory leaks.

you can find a fixed version here :

this fix also removes the effect of remanence you could see in the canvas :
previous packets were still displayed
although they should have disappeared from the system.
now, this effect has gone and maybe you really wanted it.
in that case, you have to simulate this by using pdp_reg objects.

as regards to the pdp dumps, these only happen in threaded mode,
it means than a pdp object didn't had the time to process a packet
before the next one arrives.
well, you can have a little of this and still have a stable system,
that was not really the problem here.
if you want to remove them totally,
run in non-threaded mode.


Ian Smith-Heisters wrote:

>Here's the patch and an abstraction for it, I added some comments to make it a bit clearer. At this point it
>displays 2 160x120 videos (one live, one captured from the live one) at any one of 9 places on the pdp_canvas
>(it's intended to have 8 recorded clips and 1 stream running). Use the [pd make001.mov] to capture a clip from
>the stream for the yqt player.
>Could the pdp_dumps be from having a slow hard drive? The main difference between this and the Gem replacement
>I've done for it, is that Gem is using buffers to store images, rather than the hard drive.
>Thanks for your help,

More information about the Pd-list mailing list