[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] The state of MRTs
On Tue, Mar 27, 2012 at 2:38 PM, Gregg Tavares (勤) <email@example.com>
On Tue, Mar 27, 2012 at 11:31 AM, Kenneth Russell <firstname.lastname@example.org>
It appears that only a tiny fraction of mobile devices support
multiple render targets today
problem won't go away ever. Waiting a year or 2 years, or 5 years won't
change the fact that there will always be devices where
MAX_COLOR_ATTACHMENTS is less than other devices.
... and it's frustrating,
as a developer (from time to time) of games, to be told that I'm not
allowed to develop WebGL games unless they work on bottom-end devices
that I'm not interested in targeting anyway. If you try to force
developers to do extra work to support something that they don't want
to, they'll turn their backs and keep writing native applications where
they're allowed to make their own decisions.
Prioritizing features and development time is fine. It's fine to say "we have limited resources, and we want to put them on other things right now". But, the "supported by mobile" metric just doesn't make any sense. That'll forever keep WebGL years behind competing platforms.
Note that you *don't* need to worry about there not being any games that'll work on mobile if you expose non-mobile extensions. If you expose MRT and other currently desktop-class features to WebGL, many people will still want their games to work on mobile, and mobile systems will still have lots of reasons to support WebGL. You just need to make sure it's easy to do so (eg. a capability profile extension set). You don't need to try to force people to support mobile in 2012; that'll take care of itself.
On Fri, Mar 30, 2012 at 5:24 PM, Kenneth Russell <email@example.com>
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.
The "ecosystem" is inherently fragmented, since it's very easy to write software that requires GPU features (fill rate, texture units) that mobile hardware can't provide. Anyway, you always need to test on mobile if you want an app (especially a game) to work on it, since controls are so different. If you want your stuff to work well on mobile, you have to test on mobile already.
You're not preventing fragmentation, you're preventing adoption.
Making all WebGL apps "just work" on all systems is long lost. If you want to make it easy, for developers who *want* to (and that's a lot of them!), to write apps that will work on mobile, then you need a capability profile system. I've suggested this before (https://www.khronos.org/webgl/public-mailing-list/archives/1109/msg00019.html), but didn't get any responses. I still think that's a good idea, even with the feature set that exists today, and I'd be happy to help hash out details for something like it if there's any serious interest in it.