7 ms·
This situation reminds me days when we, at W3C HTML5 WG, were trying to sneak SQL specification into HTML5 "umbrella". And one particular flavor of it - the SQL
by c-smile 9y ago
This situation reminds me days when we, at W3C HTML5 WG, were trying to sneak SQL specification into HTML5 "umbrella". And one particular flavor of it - the SQLite's SQL as it was defined at the moment of writing.
Haven't got through for many good reasons as we know.
As of GPU exposure to the Web ...
It makes sense only when we will have stable and unified GPU abstraction. As for now DirectX.12, Vulcan and Metal are close but different.
Like the WebGL that is (more or less unified) OpenGL. But even that looks too foreign to HTML/CSS/script - immediate mode rendering in architecturally retained display model of web documents.
And conceptually: HTML5 umbrella is large but not infinite.
3D rendering is too far from HTML "endless flat text tape" model.
I remember those <applet> days when browser was used as a component delivery platform for stuff that does not fit into DOM and structured yet styled text. That was conceptually the right way "to grasp the immensity".
These days, with WebAssembly, we have another incarnation of the <applet> idea and I think GPU functionality belongs to it rather than to HTML. GLSL to be expressed in WebAssembly bytecode terms but not in JS.
Web standards have to be backward compatible and I doubt that current still ugly GPU paradigms will survive on the long run. Like tomorrow someone will come with practical voxel based system instead of current abstract vector ones, what will we do?
- revelation 9y agoThis is a bit of a rambling mess, but to just make one point: the winner has been chosen. Android is implementing Vulkan, and so Vulkan it will be.
- dleslie 9y agoIt will be Vulcan and Dx12. Microsoft is nothing if not a stubborn 800 lbs gorilla.
- revelation 9y agoEh, not for WebGL it won't. Nobody even implements DX other than high-powered desktop GPUs. Will it live on? Sure, we will still have games and Xboxes. But if you're going to pick a standard that can work on mobile and desktop, there is no contender other than Vulkan.
- sitkack 9y agoWebGL can cover 87.3% of game revenue.
- floatboth 9y ago> Nobody even implements DX other than high-powered desktop GPUs err, Intel iGPU, available in something as tiny/low-power as a LattePanda board… and all the Windows tablets…
- pjmlp 9y ago1. Vulkan is an optinal 3D API on Android 7.0 and later devices. 2. Vulkan is not allowed on UWP apps 3. Even on Switch, Vulkan is not the primary 3D API.
- vetinari 9y ago1. It is mandatory if the device claims to support VR mode; 2. Nobody (in Joel's on Software sense) is writing high performance 3D UWP apps anyway.
- pjmlp 9y ago1. Basically Google and Samsung 2. UWP requirements apply to any Windows store game and Microsoft already started to be more bully about it 3. There is hardly any Vulkan game worth playing that isn't DirectX 12 as well.
- deleted 9y ago[deleted]
- pjmlp 9y agoJust like Apple, Sony and Nintendo.
- orbitur 9y agoIf Vulkan is the future, I wonder how mobile devs will make money if they can't target iOS.
- deleted 9y ago[deleted]
- pjmlp 9y agoIt is a non issue thanks middleware.
- Rusky 9y ago> Like tomorrow someone will come with practical voxel based system instead of current abstract vector ones, what will we do? For one thing, any new approach will still have to solve the same problems around data transfer and formats that make up a lot of current APIs. And for another, no matter how good this hypothetical new approach is, the old one will still be around to handle existing content and workflows forever anyway.
- colordrops 9y agoHTML and CSS are slowly losing ascendancy as the main render surface for web apps. The canvas provides a standard pixel buffer for both JS and compiled applications, making HTML's limitations no longer a restriction.
- lr4444lr 9y agoFrom your lips to God's ears.
- stu_k 9y agoExcept that rendering everything to canvas is not accessible to people with certain disabilities. Also mentioned recently here https://news.ycombinator.com/item?id=16347216 https://news.ycombinator.com/item?id=16347216
- vincentriemer 9y agoAt least until we get the AOM: https://github.com/WICG/aom/blob/gh-pages/explainer.md https://github.com/WICG/aom/blob/gh-pages/explainer.md
- pjmlp 9y agoSadly, I would that 99% of companies don't care, unless mandated by government regulation.
- zxxon 9y agoSimply doing things with HTML doesn't magically solve accessibility issues, either. A simple DOM representation could be used as a fallback, if possible.
- c-smile 9y ago<canvas> by its specification mandates pixel buffer to be placed in memory with per pixel access. This reduces GPU acceleration options to the ground.
- tlb 9y ago
- ZenoArrow 9y ago> "This situation reminds me days when we, at W3C HTML5 WG, were trying to sneak SQL specification into HTML5 "umbrella". And one particular flavor of it - the SQLite's SQL as it was defined at the moment of writing. Haven't got through for many good reasons as we know." Can you elaborate on the arguments against a dialect of SQL being available for use with local storage? I can only think of arguments in favour of it. Would be good to understand the grounds on which the idea was dropped.
- thristian 9y agoThe lesson of the Web is that when you expose some interface for people to use, they will start depending on documented features, undocumented features, and downright bugs of the first popular implementation. Second and subsequent implementations will need to spend a bunch of time reverse-engineering those bugs so they can be documented and reliably implemented in future so that existing websites keep working. The only alternative is to make sure all new interfaces have multiple, popular implementations simultaneously, so that authors can't afford to take advantage of bugs in one implementation. This is the sort of activity you see in WHATWG these days. The problem with "a SQL dialect" being available for use on the Web is that every browser intended to use SQLite as the backend. Nobody wanted to invest the time and effort to write a second, compatible, equally-reliable implementation; nobody wanted to exhaustively research and document bugs and flaws in that specific version of SQLite; nobody wanted to commit to back-porting security fixes from later versions, or forward-porting the required bugs to later versions. And since nobody wanted to do the work to make it possible, using SQL for local storage remains impossible.
- leoc 9y agoIs there a JS SQL/relational library out there that saves to local storage?
- sitkack 9y agoThe W3C attempted to say version X.Y.Z of SQLite will be the SQL standard for the web, mandating 1) that it be frozen in time 2) that the only way to be compliant was to put SQLite into all browsers, bit for bit, there would be no other way to be compliant. As much as I wanted it, and was bummed that Mozilla protested so much, they were/did/are doing the right thing by saying that SQLite cannot be used as a standard, it isn't a spec. What one can do, is compile SQLite to emscripten or wasm, or write a SQL engine in JS and use that in the browser. That is totally fine. https://github.com/kripken/sql.js https://github.com/kripken/sql.js
- kevingadd 9y agoThe SQL situation is a bummer. It made sense to avoid a monoculture, but indexedDB is a near-useless wreck due to its terrible performance and it has no meaningful querying primitives at all so you get to implement them yourselves and the performance is even worse. Wish we could've just had two SQL implementations. There are other ones out there - Microsoft ships JET and an embeddable version of MSSQL, someone could've embedded postgres or something. As-is people who care about performance are just going to compile SQLite down to wasm/asm.js and run it in a worker.
- seanmcdirmid 9y agoCanvas is immediate mode rendered and already breaks through the DOM. There are also popular movements to make the DOM appear more as an immediate mode abstraction (React). In contrast, most retained mode 3D abstractions are seen as pretty bad.
- pjmlp 9y agoThe majority of game engines scene graphs are retained mode 3D abstractions. Everyone thinks that they can do better with an immediate mode API, then we start building some kind of data structure to track down what needs to be drawn and when, with the result being similar to the traditional joke of half-implemented Lisp or ORMs, but applied to retained mode rendering. Sure, some experts manage to get it right, and those are the ones that get to write AAA game engines, but many don't.
- monocasa 9y agoBut, the real difficulty seems to be writing a retained mode abstraction that actually fits everyone's use case. I can't think of a retained mode API that works as well for RTS games as it does for FPSs, to say nothing of non-game uses like CAD.
- pjmlp 9y agoWhat are the issues you think Unity, Unreal, CryEngine, Cocos2d-X, ligGDX, OGRE, SceneKit have with RTS rendering?
- seanmcdirmid 9y agoEveryone needs their own retained mode API for sure, it’s just too different to generalize. Ideally, you would want to take your model and directly turn that into your UI, adding dependency tracing or domain knowledge to handle invalidation. React and it’s ilk make it easier to do just that.
- zxxon 9y ago>> The majority of game engines scene graphs are retained mode 3D abstractions. ... but they are not built on an abstract retained mode API. That would be the wrong level of abstraction for a Web API that people can build on properly. I think that's the point here. Unfortunately, Web APIs tend to be far too high level while missing out on low-level hooks, like the disaster that is Web Audio (and media playback in general).