Compatibility is hard (or why JWZ is wrong)

Recently Jamie Zawinsky (who famously worked at netscape in the early days) wrote an artical about how he ported xscreensvaer to the iphone. One of the main issues was that the iphone (and android, and webgl, etc) only supports openGL ES, so he had to write a shim. The question is, should the khronos group have take the immediate mode stuff out of opengl es? Given that open gl es was intended to be an incompatible version that drops support for a lot of legacy stuff, immediate mode was what was going to be dropped, since anyone who wants to write a performant opengl program on modern hardware didn’t use this anyways. However jwz’s suggestion was that immediate mode stuff be emulated in a library that uses modern techinques to implement the immediate mode API. I think that’s a bad idea to be in the standard, and here’s why: You don’t want to subtly change the semantics of something so basic. If you want a compatibility shim like this, you want it to be statically linked so you have control over it, otherwise every system could slightly change how your program works. xscreensaver is a pretty trivial program compared to almost any game, and even in that small program, he’s seeing little compatibility issues with the rendering.

Maybe opengl should never have made ES (though having something so small to implement makes things like webgl much more feasible especially from a security point of view), I don’t know enough about the details of modern graphics hardware, what sorts of systems they were trying to get opengl on when they created es. However changing the semantics of such a basic part of the api would cause much more of a problem then forcing people to rewrite. Desktop (for lack of a better term) opengl has a pretty good deprication policy. Things are marked depricated in one version, and can be removed in future versions, but you can always force an older version of opengl.

I do think that removing something from an API is not something you do overnight, it’s not something you do without a solid deprication policy, and it’s not something you do unless you really need to. I’m generally in favor of keeping compatibility, but like anything else, you need to balance it with other concerns.