> What *is* the baseline hardware fg ought to be aiming at?

I guess in practice every developer works such that stuff runs well on his own 
system. What else can we do? I'm not buying a second computer just to test how 
it would run on a Mac.

> Advances in quality always requires more resources. Period. If your
> hardware doesn't support it, bad for you but be grateful FlightGear at
> least provides an option to turn to less nifty rendering.

Actually, as Stuart or Mathias have demonstrated here, that's not always true. 
We seem to be getting more random buildings for less framerate impact for 
instance. Same was true with the clouds or with the geodinfo() which suddenly 
was a factor 50 faster.

There are sometimes clever ways of doing a task much faster, and one has to 
spot them.

More often, there are clever ways to do a task a bit faster. Taking a week to 
streamline shader code, I have typically gained 10-20% improvement in the past, 
at the expense of making the code difficult to understand. Not much, but I 
notice it, especially summing up several such effects. I didn't get the 
impression we usually make things as efficient as they could be. Many 
slow-changing quantities are determined per frame, or when it's clear that 
they're not needed for instance. An example is ridge lift which is updated per 
frame at agl altitudes of 20.000 ft when its value is ~1e-5 and it's clear that 
there can't be any real lift. Many distance calculations in Nasal scripts in 
the visible scene use spherical geometry while they could be in local Cartesian 
geometry which is about a factor 5 faster to compute.

The problem with making things efficient is that you have to understand well 
what you're doing. If you approximate an expression by something that works 
faster with the same accuracy in most cases, you need to take care of the case 
when it doesn't work. It's a weakness of the modular structure of the 
Flightgear project that there's hardly anyone with the 'big picture' who knows 
enough to realize where computations are repeated and how we could streamline 
the whole.

So, I think we can agree that spending performance on improvements, optionally 
implemented, is reasonable and desirable, burning performance in inefficient 
code is not desirable, but how to translate this into practical consequences 
isn't as easy to see. People are trying as a rule.

Cheers,

* Thorsten
------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second 
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Reply via email to