[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] The state of MRTs
I've been following this thread for a while and I have to admit that the continued insistence on "protecting" WebGL from things that might not work on mobile is very confusing to me.
For one, there aren't a lot of mobile devices right now that can actually support WebGL in any meaningful sense. Opera on Android seems to be the best so far but even there the performance is pretty bad when you compare it to what the device is actually capable of. In fact, the only mobile device I've seen run WebGL respectably is the iPhone/iPad, and that's currently not something you can see without having a developer account. Point being that if we were to restrict ourselves to writing WebGL apps that work nicely between mobile/desktop it would all look like Starfox
for the time being.
I do expect that situation to improve in leaps and bounds in the near future, as I can see this easily becoming a selling point for mobile devices and browsers, but in the meantime I see nothing wrong with wanting to flex the muscles of WebGL on the desktop. Besides, isn't that why this is being proposed as an extension and not a part of the base spec? It's common sense to check to see if your extension query returned an object, at which point it's on the developer to either take a different render path or notify the user that their device doesn't meet the requirements for that app. Although I would like to see as few apps as possible lock out mobile, I also don't want to sacrifice the possibility of WebGL having it's own version of the Samaritan
demo at some point simply because not every WebGL capable device can run it.
That said, I do think it's sensible to try and inform users as much as possible when their WebGL application is doing something that will not be mobile-friendly, since the last thing we want is for people to inadvertently exclude mobile and not understand why. I've seen several charts tossed around on the mailing list giving compatibility of feature X on chipset Y. If those are available in a sensible format somewhere publicly (or can be made so) I think it would be a great idea to put together some browser extensions that monitor the extensions that a WebGL app loads and provide the user with a "Mobile health report" for their app, detailing what features they're using that may affect mobile compatibility. Alternately the same extension could be used to "simulate" the feature set of a device class by restricting the extensions that can be used. I'd be happy to help with the development of such a tool if it gets us to stop bickering about what features we can and can't support due to mobile.
On Wed, Mar 28, 2012 at 2:18 AM, Florian Bösch <firstname.lastname@example.org>
I do not understand your point. What is the pain you are referring
Pain, conflict, clashing desires. You want two mutually exclusive things, MRTs and cross desktop/mobile compatibility. The discrepancy between desktops and mobiles is the measure of pain. It's 13% vs. 80%. So looking at it purely from a number point of view, your pain is 67%. Desktops will grow the remaining 80% in the next 2 years or so to nearly 100%. How much will mobiles grow? 5%? 10%? So in two years we'll be talking a pain of 77% perhaps. If you're committed to waiting out the pain, you're in for a long wait.