X-Plane 930 Performance and Crashes

I have received a number of emails bringing up crashes and performance problems in the X-Plane 930 betas - some of the writers are concerned that 930 might be a lame patch, going final with crashes and lousy performance.

To assuage this concern, let me make a few comments on where we are in the beta process, the likely future schedule, and the problems themselves.

The Schedule

X-Plane 930 has been an absurdly long beta. Going into the beta I had the mindset that we should take the beta slowly to have time to discover driver bugs on a wide variety of hardware - why rush and miss something?

I think we took this too far. To run a "slow" beta we have run other development simultaneous to the beta, but that in turn has stretched the beta to epic lengths.

We are starting to try to clamp down and close out the beta now, but it is going to get interrupted again. Austin and I will be traveling to attend the X-Plane conference in France, and from there we will spend two weeks working with Sergio in Italy. Given how rarely we go to Europe, we cannot pass up the opportunity to work with Sergio in person - we have a few problems in the sim where getting the three of us in one room is the best course of action.

Unfortunately our internet connectivity during the trip will be limited, and we can only bring some of our equipment, so closing out the beta while on the road is really not an option. Thus there will be yet another beta delay. Hopefully when we return, we can close the beta out for good.

Performance Problems

I have seen a number of emails regarding framerate with 930. A few notes on framerate and betas:

I try to save framerate for last in a beta. Most performance problems have two possible causes.

1. We communicate with the video card driver in a way that is fast on our systems but astoundingly slow on other systems. We discover this from slow performance in a particular piece of the code on other hardware.
2. The new beta does something new that is more expensive than what the old build did, and users have not figured out how to (or do not have a way to) turn this more expensive option off.

The solution to case 1 is to use another driver call; the solution to case 2 is to make sure the rendering options provide a way to turn the feature off. (We simply cannot guarantee that a new, nicer looking feature run without a fps penalty - we can only give you a choice between better visuals and faster fps.)

Either way, framerate work tends to be the last thing on my beta list for this reason: other bug fixes may cause framerate problems, typically in category 1 - that is, a bug fixes makes use of a new driver call that we find out has hurt performance. Thus I try to do all performance fixes at the end of beta when we won't be adding new code.

This means that in practice, I have spent nearly zero time looking at performance. I am just starting that process this week, so it will be a little bit before I find problems.

Unfortunately often performance problems manifest only in the hardware I do not own - despite having a pile of computers in my office (a pile that seems to grow deeper and less manageable every year) there are just a ton of systems out there. So a lot of the performance bugs will get fixed by users trying experiments and reporting back to me - a slow process despite some of the really great efforts by our users.

Crashes

Crashes sometimes are manifestations of gross code defects, but often they fall into the category of driver problems too. I will be working to piece together the puzzle of strange behavior over the next few weeks; usually the solution is to not do some action that we thought was legal but fails in some hardware cases.

Don't Panic

As always, my final message regarding the beta is: don't panic. When it gets quiet over the next few weeks, it is because of travel, and even once Austin and I are back in the office, it will be slightly slow going to piece together problems on hardware other than our own.