[openvrml-develop] Re: Speed Issues

[Damian M. <da...@er...>]

A while ago, I mentioned ...

> The killer, at least for the type of data we have, appears to be the
> call to
>
> 	gluScaleImage(....)
>
> Eliminating this call during operations reduces load time from 24 seconds
> down to 15 seconds.  Mind you, the only way to properly eliminate this
> call is to preprocess your images before to ensure your images are nice
> sizes when they hit memory.  That almost seems like a mandatory item when
> using OpenVRML.  Preprocess your images or suffer a performance hit.

Or, better still rewrite 'gluScaleImage'.

Going to Mesa and #define'ing it to use point-sampling instead of using
the standard OpenGL box filter does the trick also.  The box filter
exercises the CPU something fierce.  This really needs to be rewritten
using templates but that can wait.

This routine only manipulates the image. It does nothing graphically.

> However, a quick perusal of the code shows us that in the line where this
> routine is (effectively) called that we have a comment there which warns
> us ....
>
> 	      // Always scale images down in size and reuse the same pixel
> 	      // memory. This can cause some ugliness...
>
> Can anybody enlighten me as to the ugliness that this will cause?

Let's look at the fundamentals of the box filter used in the original
routine. Assume you have a VRML scene which say visualizes features which
are sharp. If you are applying the texture at approximately the same
resolution as the texture image was stored at, then, yes, you will get
some ugliness because sharp features might get smoothed.  The point
sampling method avoids smoothing/blurring of sharp features as and the
performance saving is big, big, big.  Mind you, you can probably find
images where smoothness is an issue and this can also cause grief.

We had jobs where the processing of the initial VRML load was taking 10
seconds, and the graphics 1 second, and then 191 textures took 20 seconds
to process on a 1000Mhz PIII.  On a Celeron 550, load processing went down
to 20 odd seconds from something approaching 2 minutes.

Thanks - Damian (McGuckin)

Pacific Engineering Systems International, 22/8 Campbell St, Artarmon NSW 2064
Ph:+61-2-99063377 .. Fx:+61-2-99063468   | unsolicited email not wanted here !
Views and opinions here are mine and not those of any past or present employer