Xplo Eristotle wrote:
> A post on p.b.i reminded me of something that's been bugging me for a 
> while: when using mosaic rendering, each successive pass recalculates 
> every pixel. Wouldn't it be a great deal faster to save the data and 
> only calculate color information for new pixels?

If you're doing it for preview renders, it might be nice as well have an 
option to use "solid guessing" like fractint did.  I suppose this would 
be like making the decision to render pixels on later passes or not the 
same as for AA, only render if the next one over is "sufficiently" 
different.

-josh

Post a reply to this message

Le Forgeron wrote:
> 
> You do not have to use mosaic preview, at least not until 1x1 pixels.
> That's a better boost.

Congratulations. You've just missed the ENTIRE point of the feature.

-Xplo

Post a reply to this message

Pandora wrote:
 >     Why the need to keep it memory - are their really any modern computer
 > systems that don't allow complete random read-write access to files ?
 >     Think about Windows virtual memory files and you'll see there's 
no need
 > to actually keep the whole image in physical memory...

True, but then wouldn't you take a performance hit all over again?
Consider the classic question "Should I invest in a better CPU or
more memory to improve my raytracing speed?" (to which the
classic answer, of course is simply "Yes")

On large data sets, of course you get more bang for your buck
from memory because of the performance hit that falling back on
virtual memory gives you. Similarly, if you had to read the old
data from file might it simply cause enough performance loss to
render the new feature's efficiency moot?


-- 
@C[$F];
The Silver Tome ::  http://www.silvertome.com
"You may sing to my cat if you like..."

Post a reply to this message

"Charles Fusner" <cfu### [at] enternet> wrote in message
news:3D7### [at] enternet...
> Pandora wrote:
>  >     Why the need to keep it memory - are their really any modern
computer
>  > systems that don't allow complete random read-write access to files ?
>  >     Think about Windows virtual memory files and you'll see there's
> no need
>  > to actually keep the whole image in physical memory...
>
> True, but then wouldn't you take a performance hit all over again?


    Yes, you're going to take a slight performance hit, but on a modern
machine, with a decent harddisk and some intelligently written buffering
code (i.e. you keep the areas of the image that are most likely to be
accessed in memory, rather than accessing a file on disk for each and every
pixel) that hit will be negligible.

--
Pandora/Scott Hill/[::O:M:C::]Scorpion
Software Engineer.
http://www.pandora-software.com

Post a reply to this message

Pandora <pan### [at] pandora-softwarecom> wrote:
> that hit will be negligible.

  Nope. Accessing the disk, even when cached by the OS, is always very very
much slower than accessing a memory location (given that it's not swapped to
disk, of course). Of course the disk cache makes the operations a lot faster
in the average (compared to the case where each disk read really reads data
physically from the disk), but they are still very much slower than a direct
memory access.

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

"Warp" <war### [at] tagpovrayorg> wrote in message
news:3d7341da@news.povray.org...
> Pandora <pan### [at] pandora-softwarecom> wrote:
> > that hit will be negligible.
>
>   Nope. Accessing the disk, even when cached by the OS, is always very
very
> much slower than accessing a memory location (given that it's not swapped
to
> disk, of course). Of course the disk cache makes the operations a lot
faster
> in the average (compared to the case where each disk read really reads
data
> physically from the disk), but they are still very much slower than a
direct
> memory access.
>


    I know. But if the buffering is written intelligently you can minimise
the hit - a bit like the buffering currently used in POV, but with the added
ability to be able to read & write to any part of the image at any time -
sucking a whole 1Mb off disk in one go, adjusting (i.e. reading the data
that's there an updating it or writing new data based on what's there) half
of it and then writing the whole 1Mb back in one go is far faster than
reading/writing 1/2Mb in single byte steps...
    Of course, direct memory access is quicker, but if you're trying to
anti-alias an image with a width of say 400,000,000 pixels (that's over 1GB
per line!) when you've only got 1/2GB of physical memory is going to fail
each and every time, unless you have read-write buffering... (yes, this is
an _extreme_ example, but it illustrates my point quite nicely - the same
applies to much smaller images once you take into account the memory used
for the scene description, program & O/S)

--
Pandora/Scott Hill/[::O:M:C::]Scorpion
Software Engineer.
http://www.pandora-software.com

Post a reply to this message