> How does one do that?

ln -fs /dev/null Memory.log

	The major drawback with this simple workaround is that you have to
create such a symlink in each and every directory where you run povray.

> But does it also solve the
> resource use issue (render speed)

	Shot answer: no.
	Long answer: the Debian build includes in particular some code
that checks memory access (and also makes memory usage larger).  This
and other things will slow down rendering.  I never did any serious
testing though, and the slowdown could be in the order of a few percent
only.  OTOH, especially with fast renders, without writing the Memory.log
file to disk (as proposed above) could also somewhat reduce the slowdown.
But in the end you'd better live with a binary that contains no debug code
at all.

or am I better off getting an official
> version?

	Yes.  Or even better: build your own.  Especially if your machine
is built around a SSE2-compatible CPU.

	- NC

Post a reply to this message

Thorsten Froehlich  wrote in message <45ae506a$1@news.povray.org>:
> The official version builds easily from source.

The problem with undocumented obsolete functions of libpng has been fixed?
That is good news.

Post a reply to this message

Nicolas George wrote:
> Thorsten Froehlich  wrote in message <45ae506a$1@news.povray.org>:
>> The official version builds easily from source.
> 
> The problem with undocumented obsolete functions of libpng has been fixed?
> That is good news.

That never was a POV-Ray problem, but a libpng backward incompatibility problem.

	Thorsten

Post a reply to this message

Thorsten Froehlich wrote:
> Nicolas George wrote:
>> Thorsten Froehlich  wrote in message <45ae506a$1@news.povray.org>:
>>> The official version builds easily from source.
>> The problem with undocumented obsolete functions of libpng has been fixed?

And I might add, the functions were neither of what you claim. Plus, it only
happened when building with libraries other than the ones included with
POV-Ray anyway. As POV-ray includes the correct library versions, it is a
non-issue. BTW, you spreading FUD in this thread really is inappropriate :-(

	Thorsten

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
> As POV-ray includes the correct library versions, it is a
> non-issue.

If it helps in the anti-FUD department, what started all this excitement for
me was that I put one superellipsoid in a scene and did not perceive a
render speed slowdown.

So I added a half dozen more, some with concurrent surfaces, as part of a
major overhaul with multiple SDL changes across multiple includes and saw
some screwy behavior. Ultimately, it all boiled down to the render speed
slowdown due to multiple supers, but it took quite a while with my mental
resources to make this deduction.

I'm at least official now on two boxes.

Post a reply to this message

Thorsten Froehlich  wrote in message <45b094e7$1@news.povray.org>:
> And I might add, the functions were neither of what you claim.

Well well well, let us see.

Would you care to take a look at your own tarball, the file
povray-3.6.1/libraries/png/pngwutil.c, near the line 1717? I can see there:

/* Internal use only.  Called when finished processing a row of data. */
void /* PRIVATE */
png_write_finish_row(png_structp png_ptr)
{

And I can see that the "internal use only" was there since the 1.0.0 release
at least.

So I grant you: I was wrong telling that PoV uses an obsolete function: it
uses a function that it should _never_ have used.

>								 Plus, it only
> happened when building with libraries other than the ones included with
> POV-Ray anyway.

Except that the build system with use the system libpng if it is recent
enough.

Well, sometimes, two bugs correct each other: PoV's ./configure uses strcmp
to compare version numbers, and therefore thinks that 1.2.15 is older than
1.2.5.

>		  As POV-ray includes the correct library versions, it is a
> non-issue.

Statically linking with an older, possibly buggy, version of a library is
hardly a good solution.

>	     BTW, you spreading FUD in this thread really is inappropriate :-(

I was not spreading FUD: I was genuinely glad I would be able to build PoV
without making knots to my brain. It appears that was a misunderstanding,
and the problem is still there. Too bad.

Post a reply to this message

Nicolas George wrote:
> So I grant you: I was wrong telling that PoV uses an obsolete function: it
> uses a function that it should _never_ have used.

Considering that one of the authors of the PNG library was also the author
of the PNG support in POV-Ray, your argument has neither head nor tail. Sorry.

	Thorsten

Post a reply to this message

Thorsten Froehlich  wrote in message <45b37458@news.povray.org>:
> Considering that one of the authors of the PNG library was also the author
> of the PNG support in POV-Ray, your argument has neither head nor tail. Sorry.

Well, that explains how he knew of this undocumented function in the first
place. But I do not buy arguments of authority.

Functionally, PoV has no more ties to libpng than GdkPixbuf or dvipng. So
there is two cases:

- either png_write_finish_row is a legitimate function to use in a client
  program, and it should have been made public;

- or it is indeed private, and it should no more have been used in PoV than
  in any other client program.

Obviously, the libpng team has decided in favor of the second solution.

Post a reply to this message

> PoV's ./configure uses strcmp
> to compare version numbers, and therefore thinks that 1.2.15 is older than
> 1.2.5.

	Yes, I am well aware of this problem.  When the 3.6.x series were
released in july-august 2004, this code was not considered problematic,
i.e. only a potential future issue that I was planning to fix in the
upcoming 3.6.2 release.  However 3.7 came into play in between and
we still don't have a 3.6.2.

	- NC

Post a reply to this message

> - either png_write_finish_row is a legitimate function to use in a client
>   program, and it should have been made public;
> 
> - or it is indeed private, and it should no more have been used in PoV than
>   in any other client program.
> 
> Obviously, the libpng team has decided in favor of the second solution.

	IIRC this particular libpng function is available again in the
recent libpng releases.  Which would mean that the second possibility
you list above is not as "obvious" as you believe.  One might ask the
libpng devel team to clarify this point (e.g. to update the docs).

	- NC

Post a reply to this message