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 <depth>x<depth>
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...


Attachment: PGP.sig
Description: This is a digitally signed message part

Reply via email to