comp.lang.idl-pvwave archive
Messages from Usenet group comp.lang.idl-pvwave, compiled by Paulo Penteado
Home » Public Forums » archive » Re: Object graphics under Linux: are they supposed to be that slow?
Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend  		Return to the default flat view Create a new topic Submit Reply
Re: Object graphics under Linux: are they supposed to be that slow? [message #29116 is a reply to message #29029] Wed, 30 January 2002 10:23 Go to previous message
karl_schultz is currently offline  karl_schultz
Messages: 13
Registered: August 2001
Junior Member
David Fanning <david@dfanning.com> wrote in message news:<MPG.16c12aa8f85252b59897e1@news.frii.com>...
> Mark Hadfield (m.hadfield@niwa.co.nz) writes:
>
>> The configurations are:
>>
>> * IDL 5.5 on Windows 2000 using RENDERER=0 (hardware)
>> * IDL 5.5 on Windows 2000 using RENDERER=1 (software)
>> * IDL 5.5 on Linux. This uses RENDERER=0 but, as is obvious from
>> the DeviceInfo string, the rendering is carried out by the Mesa
>> software library and does not access any hardware acceleration
>>
>> The geometric-mean elapsed time figure provides a rough ranking of the
>> configurations:
>>
>> Windows RENDERER=0 4.58 s
>> Windows RENDERER=1 3.11 s
>> Linux 5.55 s
>
> Just to give you something to chew over, Mark. Here are
> my results with IDL 5.5 on Windows 2000, with a 32MB
> NVIDIA GeForce 2GTS graphics card. Screen resolution
> is 1280 by 1024 at 32 bits True-Color.
>
> Windows RENDERER=0 0.71 s
> Windows RENDERER=1 1.34 s
>
> That graphics card was a couple of hundred bucks, as
> I recall. :-)
>
> Cheers,
>
> David

Here's another data point:

PIII 750Mhz Windows NT 4.
nVidia RIVA TNT2 AGP SSE. 32 bits/pixel

I'd characterize this graphics card as a medium-low range card today.
The driver uses the AGP port, which is good, and apparently leverages
the Intel SSE instructions, which is also good.

Windows RENDERER=0 9.41 s
Windows RENDERER=1 2.72 s

The hardware was MUCH slower at image operations. (GL is generally
not a good image processor) In fact, I had to disable the image
STRETCH test because it was taking way too long. The hardware really
only beat out the software at texture-mapped polygons. I suppose that
this hardware/driver package was tuned for the Quake-like games :-).
(I should check for a driver update)

While this is a great benchmark, it may not be representative of
typical IDL application usage of graphics. For example, I might think
that this test is a little heavy on images. This program was written
to monitor the object graphics performance during development and
later modification and so hits most aspects of object graphics.
Therefore this program probably isn't the best means to select a card
or even in deciding between hardware and software rendering. Looking
at the individual test results can help a bit more if you know what
sort of things you are drawing a lot.

For example, in this case, removing the image tests would probably
bring the hardware and software numbers closer together. And that
would be important to me if my programs didn't use IDLgrImage very
much.

Karl
RSI

Report message to a moderator

[Message index]
 
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Previous Topic: Integration of a complex function
Next Topic: Re: Subject : locks, semaphores, and such

-=] Back to Top [=-
[ Syndicate this forum (XML) ] [ RSS ] [ PDF ]

Current Time: Sat Oct 11 04:36:30 PDT 2025

Total time taken to generate the page: 0.80316 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.7.
Copyright ©2001-2013 FUDforum Bulletin Board Software