On Fri, Mar 30, 2012 at 3:24 PM, Kenneth Russell <email@example.com>
This is hardly a fair statement. First, there are plenty of mobile
On Wed, Mar 28, 2012 at 9:14 AM, Brandon Jones <firstname.lastname@example.org
> 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.
GPUs in existence that do a good job running good looking OpenGL ES
2.0 content. Second, during yesterday's WebGL conference call it was
indicated by at least one browser vendor that performance issues in
their WebGL implementation on Android were caused by inefficiencies in
the browser, and were being worked on. There is an expectation that by
years' end there will be well optimized WebGL implementations on
current ES 2.0 hardware. It would be shortsighted to throw out the
WebGL API's focus on portability now.
There are at least four technical issues with adding arbitrary desktop
> 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.
functionality to WebGL as extensions. First, if there is no
expectation that the functionality will appear on mobile hardware any
time soon, then the nascent WebGL ecosystem will be fragmented.
Second, if the functionality touches several areas of the OpenGL ES
specification, it will be difficult to specify it, maintain it as a
separate extension, and avoid poor interactions with other extensions.
Third, the form of the functionality needs to be carefully thought
through to avoid the situation that future mobile hardware integrates
the functionality in a radically, or even subtly, different manner.
Fourth, there is an expectation that official WebGL extensions will
never be removed from browser implementations. See
To the fourth point, perhaps some extensions could be left in draft
state indefinitely, until it becomes clear whether their functionality
would ever be folded in to the core specification, and if so, in what
form. I'm not sure whether this would help or hinder developers, since
it would basically be a statement that at some point, the extension
they are building on is going to be removed in favor of an alternative
In the case of the MRT extension proposal, I've identified some
technical issues. I'll reply to Gregg's email separately to detail
I personally would not support adding extensions to WebGL that are not
slated to appear on mobile hardware in some reasonable time frame.
Such a tool would be useful. I believe Firefox has a mode where 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.
restricts many WebGL parameters to their minimums to see whether the
content will run on a hypothetical low-end OpenGL ES 2.0 device. If
this were available in pure JS for WebGL, that would be useful for
identifying not only the use of extensions that might not be
universally available, but also incorrect assumptions being made about
device capabilities affecting the behavior of the core spec.
Personally, though, the existence of such a tool would not change my
opinion above regarding adding functionality that definitely won't
appear on mobile hardware in any reasonable time frame.
The problem I have with this argument is it seems to be applied ad-hoc
Today MRT = BAD even though a few mobile phones do support it
Tomorrow MRT = OKAY just because it's added to some future GL ES spec even though there will still be few phones that support it.
It will be 3-5 years before even 15% of phones support MRT or something other than OpenGL ES 2.0
So by the arguments made above WebGL 2.0 should not even be considered being worked on for 3-5 years. Even if a new ES spec appears, the arguments above say "no, if not enough phones". I feel like that's seriously limiting what people would like to do with WebGL for no good reason.
The other idea put forward seems to be, no MRT for WebGL 1.0. MRT for WebGL 2.0 if the next version of ES supports MRT
But given that it will be many years before a significant number of people have MRT phones you'll end up with the same situation as adding MRT to WebGL 1.0. Namely developers will do ctx.getContext("webgl-2.0") and if fails they'll either tell the user "S.O.L." or they will fall back to WebGL 1.0. How is that any different than exposing MRT in 1.0?
> On Wed, Mar 28, 2012 at 2:18 AM, Florian Bösch <email@example.com
>> On Wed, Mar 28, 2012 at 4:44 AM, Mark Callow <firstname.lastname@example.org
>>> I do not understand your point. What is the pain you are referring to?
>> 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
You are currently subscribed to email@example.com
To unsubscribe, send an email to firstname.lastname@example.org
the following command in the body of your email: