On 5/16/14 1:15 PM, Nathan Kidd wrote: > It would be controllable madness in one sense, because it needn't be for > *every* symbol the app overrides, but the intersection of (app_overrides > and vgl_uses). The real problem with that, to my mind, is what if I > override a gl symbol for some reason such that everybody is required to > use this modified version or it won't work. In this case we'd *want* > VGL to use the modified symbol.
At the end of the day, trying to change the behavior of an API library by overriding an API function within your app is a *really* bad idea for a lot of reasons. As much as anything, I don't want to work around this problem because I don't want to encourage that behavior. >> I think this needs to be pushed back to the Viewperf developers. >> Viewperf is an open source app, so it's not as if it is immutable. > > That sounds like a better approach. Will submit a ptach when I get > spare time. (ha!) If you can verify which version of Viewperf this issue first appeared in, I can at least document it. ------------------------------------------------------------------------------ "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free." http://p.sf.net/sfu/SauceLabs _______________________________________________ VirtualGL-Devel mailing list VirtualGL-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/virtualgl-devel
