I have this idea that if they split off WebAssembly, WebGL and WebAudio into a external format for applications it would be easier to implement than a full browser.
You could even implement some kind of … HTML document-reader webapp on top of that. [thinking face emoji] https://news.ycombinator.com/item?id=2131870
Feasibility of low-level GPU access on the Web
51–60 of 133 posts
Re: Feasibility of low-level GPU access on the Web
#52Re: Feasibility of low-level GPU access on the Web
#53What problem does this solve for the end user? Few sites even use WebGL for anything interesting.
I've used WebGL to visualize scientific data. It's nothing special, but the size of the data was large enough that anything like SVG or even Canvas were just slow. There is a lot of interesting stuff you can do even just in 2D in WebGL, because you're closer to the hardware.
What's annoying is that you don't get double precision or any of the compute stuff on WebGL currently. The interesting stuff isn't just graphics, but also doing computations directly in the browser.
Re: Feasibility of low-level GPU access on the Web
#54This 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…
HTML 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.
Except that rendering everything to canvas is not accessible to people with certain disabilities.
Also mentioned recently here https://news.ycombinator.com/item?id=16347216
Re: Feasibility of low-level GPU access on the Web
#55Earlier quoted context omitted.
HTML 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.
Except that rendering everything to canvas is not accessible to people with certain disabilities. Also mentioned recently here https://news.ycombinator.com/item?id=16347216
At least until we get the AOM: https://github.com/WICG/aom/blob/gh-pages/explainer.md
Re: Feasibility of low-level GPU access on the Web
#56This 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…
This 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.
If Vulkan is the future, I wonder how mobile devs will make money if they can't target iOS.
Re: Feasibility of low-level GPU access on the Web
#57Hmm... I wouldn't want a random webpage to start mining bitcoin on my computer. How would we protect against that?
Net Neutrality, right? It doesn't matter what the page does, it only matters that you are allowed to visit any page on "The Inter-Web" that you like, right?
Safari has "tab paused/reloaded due to high power consumption" (good), Chrome has "auto-mute tabs" extension (which I have turned on), I have "tab suspender" extension installed.
Basically, I'm trying to be a responsible consumer:
- this tab would like access to your hard drive files
- this tab would like access to your video camera
- this tab would like access to your microphone
- this tab would like to play sounds
- this tab would like to download more than 5mb of data
- this tab would like animation/movement
- this tab would like to use your CPU a lot
- this tab appears to be using a lot of your battery
- this tab would like to use your GPU (at all)
- this tab would like to maintain state > 24hr
the_internet.js is actually potentially really hostile (suck 9999mb at full speed, ddos@1.2.3.4, while(1){alert(1)}, mine_bitcoin( $hacker_wallet )), and I am much in favor of treating it as untrusted by default (low access, limited # of cpu cycles) until "trusted" (ie: android permissions swap: i give you the executable, you give me the permissions).
YouTube? Yes to whatever they ask.
ShadyWebsite.1234.some-random-domain.ru? You can d/l 300kb and can't do anything else (ie: web 1.0/no-script).
While each "tab" in a web-browser attempts to provide "safe" access to the computer resources, it is still not "permitted" access to computer resources. Whatever the browser defines as "safe" is 100% ok, which has to work equally well for WASM-unreal-tech-demo-castle as well as cnn.com.
I'd prefer cnn.com only had 300kb download, no external domains, no sound, no battery, no cpu, etc.
As I _trust_ cnn.com more (to the same level as youtube), I would then permit sound by default, permit large downloads, permit gpu, permit animation/video/etc.
Re: Feasibility of low-level GPU access on the Web
#58What problem does this solve for the end user? Few sites even use WebGL for anything interesting.
Most of these fads seem to be driven not by what's good for the user but what's good for the advertiser and the developer. Low level GPU access will just make it easier for them to run montero miners on my browser.
There's an ICO for that.[1] Really. They want to offer browser based virtual reality which mines tokens in the background. The initial token sale is in progress now. The virtual reality system appears to be total vaporware.
Re: Feasibility of low-level GPU access on the Web
#59This 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…
HTML 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.
by its specification mandates pixel buffer to be placed in memory with per pixel access. This reduces GPU acceleration options to the ground.
Re: Feasibility of low-level GPU access on the Web
#60There is an upcoming Xbox game (Crackdown 3) that uses web-based GPU processing to share compute amongst players in a multiplayer game.