Odd thing on RasterRable

[Thomas E Deweese <th...@kodak.com>]

>>>>> "VH" == Vincent Hardy <vh...@eng.sun.com> writes:

VH> I just noticed something odd on RasterRable. There is a create
VH> methods that takes a url and a bounds, but the bounds is
VH> ignored. The image bridge actually creates the image and then sets
VH> the bounds on the node that uses the RasterRable... Should we tank
VH> that attribute in the create method?

    Yah, we can I think I did it for symetry with SVG content, but
perhaps it doesn't make sense...

    FYI, I have been focusing on the Out of memory errors in
filters-many.  In the processes I made Composite, Flood, Gaussian
Blur, and Bump Map demand pulled/tiled.  In the end though it turned
out that when you zoomed in on the Gaussian even a fairly reasonable
levels (one zoom box) it started to require _lots_ of surround (the
std deviation was ~250, hence the number of sourround pixels required
I think is ~3x on each side or it might be both but anyway a lot).

    Since those kinds of stdDevs are just rediculous I tried adjusting
the GaussianBlurRable so it clamps the stdDev at 10 and uses an
affineRed to make up the difference.  So in the above case it would
render a much smaller version, blur with stddev of 10 and then use the
AffineRed to scale it up by ~25.  This produces visually
indistinguishable results for the tests I have run.  I'm a little
nervous about adding yet another blur hack on top of the existing box
blur hack, but it seems to have a lot of merit (fast, uses less
memory, and seems to give _very_ similar results).

    It could also be enabled/disabled on a hint (the change is
actually pretty trivial).

    What do you think?

    With this change I can now zoom in as far as I want (which really
isn't that far since you pretty quickly reach the limit of the bump
map's resolution).

    I was also going to make some changes in the Light interface, so
you could request single scan-lines from a Light and pass in the
destination array, so it can be reused from line to line (like a bunch
of the Raster interfaces).  I would keep the current interface built
on top of it.  Any opinions?


    BTW, the lighting code is sort of doomed to slowness, it's using
the equivilent of Phong shading (lighting calculation is performed at
each pixel), this is fine for off-line calculation but I don't think
it will ever be fast enough for interactive rendering (much less
animation) for anything of real size...

    I unfortunately can't come up with a great solution to this
problem since unlike a 3D model you don't have enought information to
reasonably do Gouraud shading (do lighting calc at 'verticies' and
interpolate the shading calc).  Just sort of rambling here. :)

    I'm going to look at your print problem, then make the
StaticRenderer use a tile cache (so panning is relatively quick).