[Windows Mobile Software Development] Chainfire:
Sigh... why does everybody keep assuming I don't know what I'm doing? :)

I am not disabling the framebuffer alpha. Actually 565 is the default mode on most Windows Mobile devices. No game or app expects 4444, as it is a mode that is only supported by very few devices, and the popular ones - which most dev's target - always have defaulted to 565.

What is happening is that apps and games get the 4444 by default instead of the 565 mode, when using an unpatched device. With the patch, if an app requests alpha it will get alpha, in this case it will then likely get an 8888 mode (depending on the request parameters). It's the same as the MSAA comment - if an app requests MSAA, they will still get it. No high quality features are disabled by this patch, it merely enforces a minimum quality framebuffer. It makes GL on the Snapdragon devices behave more like the GL on other Windows Mobile devices - expected behaviour wise - not less!

No Windows Mobile devices I know of default to 8888 mode - the bulk of them don't even support it. It's virtually always 565 (as this is 'normal' WM graphics mode as well). But again, if an app requests 8888 mode it will get it - and yes 8888 mode is a bit slower than 565, though not that much slower.

A large part of the problem is that some very popular WM devices from the past did not treat the 'requested parameters' right, and would simply say there are no GL modes at all if you requested anything. This lead to many apps not requesting any specific configuration and thus always using the 'default' configuration. This worked fine on all those devices because they would all use 565 mode in that case. The only real change GL configuration wise is that now Snapdragon does this as well, thus 'expected behavior' is restored.

The better written GL applications try requesting a full configuration first, and if that does not work, only then request an 'empty' configuration, returning the default mode (which the patch changed from 4444 to 565). Some of them even walk all the possible configurations and choose the one they want manually - which is pretty much always 565 or 888(8), I guarantee you it won't be 4444 because virtually no devices have it - in fact emulating what the configuration function should have done, but didn't.

These type of GL applications are not even affected by the configuration changes made by this patch. Again, there is no maximum quality limit in this patch, only a minimum quality limit. I hope all of this finally makes some sense to you, cause frankly I'm getting tired of having to explain this over and over again. Perhaps I lack the skill to explain it well...

In either case, this whole configuration thing where everybody seems to trip over and is sure removes this, or lowers quality there, etc is merely a compatibility thing for older apps. It is NOT what gives the patch the big speed-up and removes the laggyness in a lot of apps/games! The configuration thing is a pretty minor adjustment, on which way too many words have spent.

The actual 'fastness', reducing of 'choppyness', etc, for a lot of apps comes from the part of the patch that tries to fix the vsync issue!