On 02.03.2005, at 20:22, GSR - FR wrote:
IOW, supersampling is nice for the small set of cases in which it
really matters, otherwise it is going to be slower always. Of course,
it is going to be faster in many cases than full sampling and scaling
down. If anybody figures a better method than user selectable adaptive
(best case as fast as no oversampling, worst case as slow as
adaptive), I guess POVRay Team will like to hear too. :]
It might as well be that the adaption is the root of
the speed problem. As is the code is a mungo-jungo of
hardcoded computation that works differently (or at least
seems so) than other region based code. It does not
operate on tiles but on rows, does its own memory
allocation and thus is hardly parallizable and very
likely much slower than it needs to be.
And hey, 3 times adaptive supersampling blending a
layer takes *much* longer an a manual 10x oversampling by
blending a larger image and scaling it down to the
original size with Lanczos; this is a UP machine BTW.
My assumption here is that if the adaptive
supersampling code takes magnitudes longer to render
than without supersampling it could be benefitial to
simply use the common code to the render depthxdepth
times the amount of tiles to fill and simply do some
weighting on this data to fill the final tile. Very
easy, reuses existing code, runs multithreaded and is
likely quite a bit faster than the stuff now is.
I would also look into the possibility of analyzing
the inputs (gradient and repeat type) to find
degenerated cases and recommend the use of supersampling
to the users...
Servus,
Daniel
PGP.sig
Description: This is a digitally signed message part
