In article <new### [at] cx38767-adt1sdcahomecom> , 
new### [at] hoboescom (Jerry Stratton) wrote:

> Sorry, I was measuring this for my use (hence the "nonrigorous"
> adjective). I always use the preview, so the relevant speed for me is with
> preview on.

Yes, I notice that. The problem is that we already get tons and tons of
reports their version would be faster, but its technically not possible
(without POV-Ray core source code changes), at least as far as I can see
(and it is so hard to explain/prove to users in non-tech terms; I am a  bit
upset by such claims and I am sorry if my reply sounded unfriendly!). On the
other hand, their frontend is completely different, but I know how to
"eliminate" that difference (for private testing)... and I am of course
aware of the slow preview. The thing is that i.e the official preview has no
size limit at all, you can preview images up to 32767 pixels in size, yet
3.5 will definetly improve speed and offer more options to tune it to a
maximum (over the current unofficial speed).

> I no longer have the 233 to perform more testing.

Well, I don't mind to just see the other results (G3/300 and G4/400) :-)

> Both were set to display the vista buffers. The unofficial compile seemed
> to display them much faster--instantaneously, whereas the official compile
> seemed to draw each box separately.

What you are seeing is the slow drawing into the preview image buffer by the
official version. QuickDraw does not support (prior to Mac OS 8.5 and even
there not officially!) image maps over 4095 pixels in size (true color) due
to some 16 bit values that use some upper bits for flags...so the current
official version works around it by creating a offscreen out of lots of
small parts. To draw to more than one part at a time requires a fair amount
of work for switching (you can reduce switching time that by increasing the
image buffer cache size in the prefs) as the buffer is also kept on disk (as
32K * 32K pixels are 4 GB in size!). And additionally, there are some extra
tricks neccessary for the alpha channel preview.

You can also speed up the official version preview a bit by switching to
below 100% magnification. This causes fewer (re)draws while rendering and
gives a small speedup.

> That was my thought as well, so I ran that test twice; this was also the
> reason I added the "extensions off" test, in the hopes that whatever was
> causing the difference would not load. This was with the same POV settings
> that I used on the G4 and on the Rev.2 G3. As you pointed out, I did not
> use the same settings file for both compiles, but I did use the same
> settings file across machines for each compile. When I get some G4s in our
> lab, they'll be set up exactly the same as the rev.1 G3s in that lab; I'll
> see if I can do some more rigorous testing when that happens.

It might also have to do with the preview. If Apple improved the graphic
card drivers (i.e. the single pixel drawing speed), it might be that you are
simply measuring that, or other screen related things. In general, try to
avoid all graphics when doing CPU speed tests, Apple does a lot to improve
on that part, and it messes up any benchmarks frequently :-(

> Given your earlier explanation, exactly that :*)

Yes, sad but true. Without AltiVec a G4 is just a slightly better G3. The
btter subsystem Apple builds around it is much more important.

> Yes, the one from the Smellenberghs. Do those differences make sense if
> preview is on? I've occasionally turned preview off to get the greater
> speed, and just can't handle it, especially for the long renders that
> require the greater speed. I need to see what's going on!

Yes, apparently a lot of people like to k.  If just anybody had reported
that during beta testing of 3.1 so we could have changed it ... :-)

> I didn't actually switch to the unofficial compile for speed, I did so
> because I need the Object Bounds patch for working with text. (In fact, I
> had looked at the unofficial about a year ago, and decided against using
> it; I prefer the less-cluttered interface on the official compile; but I
> do a *lot* of work with text in POV, and really need the object bounds
> patch, which was recently added.)

I am not sure what this patch does (I lost track of the hundrets of patches
out there :-) , but maybe it will be in 3.5.


     Thorsten


PS: When tring the INI file idea I suggested, generate the INi file with the
unofficial version. The official version eats that file, but the unofficial
one does not eat the one from the official version.


____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message