On 21/11/2010 03:02, Stephen wrote:
> I've posted it in p.b-t.b and sent a short dump.

I've had a look at this. Part of the issue is that it hits the internal
link to frame stage with one top-level union that contains 2,116,139
sub-objects, spread amongst many other sub-unions (961,880 children at the
second level, for example). POV-Ray will flatten these out if possible and
then destroy the containing union; this causes additional memory ops (we
might like to look at making this more efficient) but I haven't evaluated
how much difference it makes vs not doing so.

During shut-down of the Windows version, if the de-allocation of memory
blocks takes more than five seconds, the worker thread is forcibly shut
down. However, this was not being handled properly within that code and
consequently Windows would issue an 'unusual termination' message, or the
program would just crash. That should now be fixed.

As for why it's sitting using CPU for a long time after the render is
finished, or crashing on another render attempt: I can't say exactly what's
going on there as I didn't see that behavior when testing.

Also, in response to your original query as to why the memory is not freed
after the render: the internal architecture of POV-Ray 3.7 separates the
scene from the render; i.e. the parsing of the scene is totally separate
from the render, and technically the same parsed scene data may be used in
multiple renders (either simultaneously or sequentially). This isn't
implemented yet (i.e. you can't actually do it) but that's more a UI
limitation than anything else. Put another way, the parsed scene data (and
hence all the memory it uses) stays around after a render until it's
explicitly destroyed, which doesn't happen until a new render starts or the
program exits.

-- Chris

Post a reply to this message