
Issues with Apple's iOS WebGL Implementation - espadrine
http://codeflow.org/entries/2014/jun/08/some-issues-with-apples-ios-webgl-implementation/
======
0x0
So... It's a beta and some limits aren't up to native spec because of things
like the UIWebView currently being backed by an OpenGL ES 2.0 surface (instead
of 3.0, which is only available on the iPhone5s)?

~~~
illumen
The author is doing a great service to WebGL by actually testing the beta, and
reporting bugs to Apple.

------
daformat
Did not get that apple was finally unleashing webGL on mobile Safari, that's
awesome! Thanks for the investigating on the beta and helping in making it
better. I can't wait to be able to have Three.js working on iOS.

Though, I feel disappointed that the promises of "web app" were not really
held so far (just look how you can't even open an external link in the browser
from a webapp now), in favor of native apps, and hope that webGL in the
browser isn't gonna be just another bittersweet thing.

I guess we can simply wait to see how the tickets you linked to will go to
have a good sense about that.

------
overgard
Apple's support of OpenGL has been notoriously bad performance and feature
wise for quite a while (at least on OSX, not sure of the mobile story), so I'm
not that surprised that their webgl implementation isn't brilliant. It would
be the most un-apple thing ever, but I wish they'd just leave it up to the
device manufacturers to provide a GL implementation directly in the same way
microsoft (generally) does. Apple has so far proven to be awful at it.

~~~
comex
Today on mobile, device manufacturers' GL implementations are notoriously
awful:

[https://dolphin-emu.org/blog/2013/09/26/dolphin-emulator-
and...](https://dolphin-emu.org/blog/2013/09/26/dolphin-emulator-and-opengl-
drivers-hall-fameshame/)

It sounds like Apple is doing well by comparison, but I don't deal with this
stuff myself at present, so I'm not sure.

------
rmrfrmrf
Apple has made it known through its chip design (and subsequent
underclocking), app development limitations, etc. that battery life is of
utmost importance. I suspect that some of these limits are an attempt to keep
websites from draining mobile devices of energy.

Is WebGL over a browser typically as performant as native code? I would
suspect no, but I'm not familiar enough with WebGL to know.

~~~
0x0
It's unlikely to be battery concerns. If anything, lack of extensions and low
limits means webgl code would have to perform multiple passes of a scene to
achieve the same visual effects, thereby increasing the battery drain. Also,
why allow these features for native apps if it's not good for the battery?

And if you click through to the webkit bugtracker, it looks like almost all
the issues listed already have patches committed.

------
TazeTSchnitzel
Why limit the iPad to iPod levels?

~~~
maccard
Because it's still not finished?

------
Lerc
I just ran the Conformance test under Firefox (30.0) and Chrome (35.0).

Firefox crashed completely. Chrome popped up a "Rats! WebGL hit a snag".

So in a sense, iOS has reached feature parity :-)

~~~
slacka
While, Firefox has been crashing for the past few versions, both Chrome stable
and canary have been completing the WebGL Conformance Test without crashing.
There is probably something wrong on your end, if it won't run on your rig.

------
fit2rule
I think its fascinating that the embrace and extend (and wall-off in a garden)
strategy being applied by Apple is still producing, nevertheless, a very
pliable audience even in this day and age.

I see the 'heading off of open standards' play of Apple in a cynical light,
because I believe Apple are playing platform games here. These
breaks/incompatibilities are another reason for developers to not bother with
other platforms, or at least limit themselves in a way that makes platform-
dependent tooling inevitable. Basically, it's developers getting screwed by
hardware guys, over and over again.

~~~
coldtea
Cross-platform is not the be-and end-all in software.

Cross-platform has the covenience (and bigger market), but it's also crippled
by catering to the lowest common denominator. You won't get stuff that takes
full advantage of a platform if it's cross platform.

Some people like native dedicated apps. I, for one, like cross platform stuff
for common infrastructure (servers, unix userland, etc), but prefer platform
specific and integrated desktop apps that take full advantage of my OS
(whether OS X, Windows or Linux).

~~~
fit2rule
To me, 'native dedicated apps' just means: letting someone else do the GUI for
you, even though it may suck.

~~~
rimantas
What does it mean, exactly?

~~~
fit2rule
It means let Apple do all the GUI work for you. And then let them change their
designs, and the design of your app of course, according to their whims.

Its okay, I understand I'm getting downvoted for not following along with the
groupthink that Apple can't do anything wrong in the GUI department, and
therefore native is far superior to anything else, but I've still got the
opinion that the native GUI toolkits/frameworks for each platform are really
designed to lock users - and developers - into the platform. Far better to
avoid this issue completely, and do cross-platform development with custom GUI
controls, if you want to have an app that works wherever your users will run
it ..

~~~
coldtea
> _Its okay, I understand I 'm getting downvoted for not following along with
> the groupthink that Apple can't do anything wrong in the GUI department_

I think this "persecution complex" is more groupthink that what you accuse as
groupthink. There are tons of discussions on HN, and highly voted comments,
about Apple's errors in GUI work (and elsewhere). They just happen to do a
better job than 80% of the developers out there.

Furturmore, I disagree with the two basic premises of your comment:

1) Native doesn't mean "let the GUI to Apple". You conflate native with
"follows a platform's GUI guidelines religiously".

You can create a great native app, using Cocoa APIs et al, that still looks
totally different from Apple's apps. Take for example Paper for iOS. Or
Procreate. Or Elements. Or tons of stuff, really.

You don't have to follow the GUI look at all, you can even have your own
widgets for stuff. Just don't try using Swing in a Mac app, or some shitty
Cocoa port on a Windows app. And let the common behavior of items like
dropdowns and text-entry boxes be the same (e.g with regard to keyboard
shortcuts).

But for those that do want to "leave the GUI" (well, look) to Apple, it's
because it saves them tons of fucking work. Redundunt work of having to
implement common stuff for themselves and their app.

2) Second, I don't think "native GUI toolkits/frameworks for each platform are
really designed to lock users - and developers - into the platform" makes much
sense.

What DEFINES a platform is the very presence of such things (native
GUIs/frameworks, etc).

Without those, what you ask amounts to OS landscape where everything is the
same generic base, sort of like FreeBSD/NetBSD/OpenBSD/etc but also at the
desktop level.

What's the sense in having "platforms" for desktop OSes at all, if that's the
case?

If you just want one OS to rule them all, for everybody, just ask for that. It
makes no sense to want to have different platforms but still be bound to not
have unique APIs and frameworks for each.

~~~
fit2rule
>It makes no sense to want to have different platforms but still be bound to
not have unique APIs and frameworks for each.

The point is, that this is an artificial arbitrary, a line drawn in the sand
by market - not technological - forces, and to play along with it is to pander
to the divide and conquer strategy begin applied in the effort to capture
developer mindshare. Why deal with it at all, when .. with a little effort ..
a cross-platform solution that works effectively on all platforms is a
tangible, viable product? Just consider the amount of work that had to be done
to update apps for the recent changes in iOS' look and feel, and consider what
life would be like if instead the effort was made on a cross-platform solution
that put the application-standard GUI together, driven by the application-
developer, not OS/hardware vendors whose motives are entirely driven by
keeping developers away 'from those other platforms'.

I've built big Android and big iOS projects. Neither one of them is better
than the other, in any sense whatsoever; both platforms have their thorns and
pitfalls, and maintaining two separate codebases, with all the pitfalls, is
just counter-productive. Better to have one codebase that fits all and keeps
the productivity where it needs to be: on the application, and not on keeping
up with the joneses ..

~~~
coldtea
> _The point is, that this is an artificial arbitrary, a line drawn in the
> sand by market - not technological - forces_

That's wrong. Platforms are different, and offer different APIs and
frameworks, because of technological forces too, not just because of some
corporate conspiracy for lock in.

Case in point, even Open Source OSes offer different platforms and
incompatible frameworks. Not all are just a UNIX/POSIX clone.

VMS has a different philosophy to UNIX. Lisp Machines even more so. Windows.
BeOS. Etc. And that's the core OS. The same goes for platforms and desktop
level stuff.

Having the same stuff (APIs, GUIs etc) work in all platforms the same, kills
diversification and competition between technological implementations and
design philosophies.

> _I 've built big Android and big iOS projects. Neither one of them is better
> than the other, in any sense whatsoever; both platforms have their thorns
> and pitfalls, and maintaining two separate codebases, with all the pitfalls,
> is just counter-productive._

Well, that's like your opinion man. I find iOS vastly superior for most of my
uses cases.

I surely don't wish iOS and Android got merged into the same codebase.

