[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] GL_RENDERER string needed for performant apps

On Wed, Jan 15, 2014 at 2:25 AM, Dean Jackson <dino@apple.com> wrote:
If the state of the art in Google Maps is to query the GPU id and turn off either AA or WebGL entirely, then it seems the more important problem was that the user experience was degraded *before* they were able to measure performance. Since people don’t update their computer too often, one way to improve this would be to use local storage to remember what the performance was. Then you’d only have to do a real test every so often. [NOTE: I’m completely aware how ridiculous it is for me to make suggestions like this - Google probably spent hundreds of engineer hours trying everything they could]

You're equating GPU information with detecting changes in an individual users performance envelope.

It's not about detecting changes to individual identified users. If you have the GPU information of everybody this changes two things:

1) Being able to correlate deficiencies for a GPU segment, improving it and see if the improvement has the desired effect on that segment and doesn't degrade performance in another segment. Unless you have a large test farm at your disposal, it's not possible (localstorage or not) to pinpoint problems to a GPU segment, change the code, and have users run the change at a large scale to see if the tweak changes things for that segment, and if you'll want to restrict that tweak to that segment because it could be detrimental to other segments.

2) If a user comes to you with a problem (app crashes, graphics glitches etc.) you usually ask him about his hardware. You can shortcut this a lot, so that's one benefit. But also, you might want to know, well if this user had this problems, is it possible users with the same configuration have the same problems? In other words, say you have users that stay 10 minutes or more, and return the other day, but you also have users that stay 30 seconds and never return, is it because they don't find you interesting, or because they have the same hardware as the user that reported the problem to you and they would be interested but just saw garbage on screen? What action you derive from that information (develop a workaround, file a conformance test, file browser or GPU vendor bug report etc.) is a different topic. But it's important to know if visitors you didn't capture, you didn't capture because of a bug, rather than because you made boring content to them.