On 5/13/11 12:11 PM, Nathan Kidd wrote: > Rather than ripping out the rug from under the user, worst-case the app > doesn't draw correctly but at least the user has a chance to save. The > trace logs will still give necessary info to know something went wrong. > > This is the logical follow-up to the previous patch. Given enough time, > I suggest an app that triggers one of these cases will be encountered. > While we don't want to start baby-sitting bad applications, we should at > least be as lenient as other known GL drivers.
I am OK with making the bad arguments non-fatal, because that is consistent with the behavior of the rest of the GLX functions in VGL. However, a failure in MatchConfig() and MatchVisual() needs to remain fatal. Arguments: (1) If such horribly-behaved apps existed, we would've encountered them by now. (2) We're not a GL driver. There are certain things in VirtualGL that are non-recoverable that would probably be recoverable in a regular GLX implementation. Visual matching is one of them. If MatchConfig() or MatchVisual() are failing, it usually means that there is a deeper interaction issue with the app, and if the function fails silently and only causes the app to render incorrectly, it's really hard to track down what's going on. Fatal errors will get reported, whereas non-fatal errors will just lead to the user saying "well, this solution is flaky" and never reporting the issue. I take a very reactive approach to developing VirtualGL, as you may have noticed. Everything that is done to that code is done in response to the needs of a specific app. I don't fix that which isn't broken yet, as a general rule, because it's been my experience that doing that often breaks something else. ------------------------------------------------------------------------------ Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay _______________________________________________ VirtualGL-Devel mailing list VirtualGL-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/virtualgl-devel
