Live data from Hacker News

Apple proposes new web 3D graphics API

webkit.org

641–650 of 650 posts

Re: Apple proposes new web 3D graphics API

#641

Earlier quoted context omitted.

Apple sold a record breaking amount of tbMBPs in the quarter since its release. The HN echo chamber is strong, but its silly anecdotes don't reflect reality.

Not true on Apple selling a record amount of Macs. Apparently they added 7 days to the quarter versus a year before and therefore Mac sales declined again. For 2016 Mac sales also declined compared to 2015. Apple Mac sales declining is tied to the lack of new OS X software, IMO. Otherwise why decline?

Here is the Apple data and you can see for 2016 Mac sales declined 14%.

http://www.apple.com/newsroom/2016/10/apple

Re: Apple proposes new web 3D graphics API

#642
post #479

Earlier quoted context omitted.

Not if you take Android into account.

Which is why I have precisely written GNU/Linux. Android is a Java based OS, which happens to use Linux as kernel, Google can very easily change it to something else. Only these set of C and C++ libraries are available to native applications on Android, which happen to be compiled to a .so anyway, to be loaded inside ART/Dalvik. https://developer.android.com/ndk/guides/stable_apis.html Trying to link into any other G…

It has the Linux kernel you just bring the GNU or whatever you need. But Google now supports containers on ChromeOS so if access you can just run in a container and the use Android X Windows server on same box.

If Google would gives this away have my perfect development solution. I can play my Android games on my 2 in 1 and then use full Linux when in laptop mode. But I can also debug my containers on my laptop as native.

But when needed I have sold browser and other core things can never be touched. Basically give me a iPad and a Chromebook and a full Linux development machine. Well no kernel dev on Linux but most things, native, shared read, etc.

But I want an extra SSD that is separate from the kernel SSD. I think this can be done and even keep read share from boot dev and something running as a container.

Re: Apple proposes new web 3D graphics API

#643
post #612

Earlier quoted context omitted.

> On this one, you are guilty until proven innocent, I'm sorry Or rather, he's got to refute the null hypothesis.

In the case of web standards, the null hypothesis is "no new API" rather than "make something that works only on top of this specific native API". For the web, the latter is not even the default assumption once you've decided something needs to be added. The web is cross-platform by design.

>In the case of web standards, the null hypothesis is "no new API"

Thanks to Apple's bone-headed decision to not support Vulkan, this is what it has come down for me when it comes to graphical APIs. For me it's either "no new graphical APIs, keep being forced to use OpenGL" or "drop macOS/iOS support".

Re: Apple proposes new web 3D graphics API

#644
post #83

Earlier quoted context omitted.

"We're not complaining, we're explaining the lay of the land." The "lay of the land" is that the rest of the world is adopting Vulkan, and therefore the right target for WebGPU is very obviously Vulkan. Even macOS and iOS can (theoretically) support it thanks to MoltenVK [0], and Vulkan is already available on Windows. Trying to wrap all three "major" native APIs is pointless when there's already one that works every…

Vulkan on Windows is all based on unofficial drivers that don't come with Windows and aren't supported by MS. We don't think it's right to depend on this even if it's theoretically possible. Likewise for unofficial macOS/iOS drivers.

I'd hardly call the drivers distributed both via Windows Update and via the vendors' own websites "unofficial". They're about as official as it gets.

Re: Apple proposes new web 3D graphics API

#645

Earlier quoted context omitted.

> But what does this have to do, when they propose a new Web API? The web being inherently cross-platform in nature there's a motivation on their part to not support it, or - in this case - cripple it (perhaps to a mild degree but at least enough to render it categorically inferior to native metal and not worth the trade-offs). I can't say that their proposal does this necessarily, but there's inarguably a motivation…

Hm, do you really believe, that Apple wants to artifical cripple the web? I see, that they hypothetically might have motivation, to do so ... but this is not valid, since the web is inferior to native implemantations in the first place! The "only" advantage of the web is, that it is more or less, cross plattform.

>the web is inferior to native in the first place

The web is de facto inferior, but it is not de jure inferior. That is to say that many people would very much like to see the web match native in capability, and efforts that derail this effort are criticized in kind.

Re: Apple proposes new web 3D graphics API

#646
Thanks for sharing this valuable information to our vision. You have posted a trust worthy blog keep sharing. Nice article i was really impressed by seeing filmywap" rel="nofollow">http://googlepc.org/filmywap-apk-app-2017-android/">filmywap app this article, it was very interesting and it is very useful for me.

Re: Apple proposes new web 3D graphics API

#648
post #486

Earlier quoted context omitted.

Firefox argued that WebSQL was a terrible idea that shouldn't become a standard, and the other vendors eventually agreed, including some that were already shipping it.

Right. "[Firefox] developers apparently being extreme zealots for [IndexedDB] and essentially refusing to implement [WebSQL] for years"

No, that is actually a serious mischaracterization, to be point of being actually malicious. The point wasn't that it had to be IndexedDB, the point was that it couldn't be WebSQL as long as the latter relied on specific SQLite implementation details.

Given that nobody wanted to fix the WebSQL proposals (they had already been deployed, and some apps relied on them, making it impossible - good job there) there was no choice but to move to another proposal (IndexedDB).

If you do not understand why tying standards to specific implementations is a bad idea, I feel sorry for you. Good for us, the rest of the industry is - most of the time - smarter than that.

Post reply on HN