[HN Gopher] WebGPU Fundamentals
___________________________________________________________________
WebGPU Fundamentals
Author : itsuka
Score : 328 points
Date : 2023-04-15 10:36 UTC (12 hours ago)
(HTM) web link (webgpufundamentals.org)
(TXT) w3m dump (webgpufundamentals.org)
| butz wrote:
| Great resource, but this website really doesn't want you going
| back to previous page.
| itsuka wrote:
| It appears that the issue only affects pages containing a code
| editor (and Firefox-only).
|
| I did a quick check and found that the editor is based on
| gfxfundamentals/live-editor, and it is doing stuff I'm not
| familiar with, such as injecting a blob for each editor and
| using some URL params hacks. I'm not sure what the issue is,
| but you can take a look at editor.js if you want to dig deeper.
|
| What's certain is that you'll need to hit the back button 1 + n
| times (n being the number of editors on the page).
|
| [edit] I have opened a GitHub issue for this
| everdrive wrote:
| I haven't kept up with WebGPU. As a more casual web user (and not
| a web developer) usually these features introduce more annoying
| webpages, as well as some new way to be fingerprinted as you move
| across the internet. Can anyone comment on this? Are there
| privacy mitigations that users should be enforcing to ensure
| their privacy is kept intact?
| fulafel wrote:
| You can disable JavaScript or WebGPU in browser prefs. (Once it
| ships...)
| geenat wrote:
| Compute on WebGPU is gonna be interesting- "crowd sourced" model
| training.
| TachyonicBytes wrote:
| This is great! I have been meaning to get more into WebGPU!
|
| One question: Does anyone know more details about the Firefox
| WebGPU story? Even on this site's homepage, if you access it from
| Chromium with WebGPU enabled, you get nice floating rotating
| triangles, if you access it from Firefox stable, you get,
| understandably, static triangles. But if you access from Firefox
| nightly, with WebGPU enabled, you get a dark background and the
| error: TypeError:
| navigator.gpu.getPreferredCanvasFormat is not a function
| jeroenhd wrote:
| Firefox doesn't implement that method yet:
| https://developer.mozilla.org/en-US/docs/Web/API/GPU/getPref...
|
| You can probably use "bgra8unorm" where
| getPreferredCanvasFormat isn't available, that seems to be the
| preference for at least Blink and WebKit.
|
| Chrome doesn't support rgba8unorm on Mac, probably because
| Apple seems to have chosen bgra8unorm as their format for their
| Metal API for some reason, so you'll have to use BRG rather
| than RGB if you want to support Apple hardware at the moment.
| midland_trucker wrote:
| The WebGL equivalent sites were a delight to go through; So well
| structured and thoughtfully displayed. It's so great to find a
| resource you can put some trust in amongst all the outdated and
| fragmented code out there.
|
| Looking forward to ploughing through this when I have the free
| time to.
| vbezhenar wrote:
| How do I render text with GPU? Do I render text on texture with
| CPU and then send that texture to GPU? Do I vectorize it and draw
| millions of tiny triangles to approximate those vectors? It's
| interesting for me to explore WebGPU as a canvas for app
| development, but it's not obvious to me how to draw text and text
| is everywhere.
| flohofwoe wrote:
| It depends on the quality and performance requirements, but you
| are basically on your own (e.g. the browser's integrated text
| rendering won't be of much help unfortunately - at least if
| performance matters). You need to bring your own font data and
| 'pre-rasterize' glyphs either on the CPU or GPU into a font
| cache texture, or render directly on the GPU using an approach
| like Slug or Pathfinder.
|
| Of course there's also always the option to overlay DOM
| elements over the WebGPU canvas if you just want to render some
| 2D UI on top of the 3D rendering.
| itronitron wrote:
| Some people have been using signed distance fields (sdf) to
| define fonts on the GPU.
| pavlov wrote:
| Note that this approach is useless on its own if your app
| needs to render user-created text because nowadays everybody
| expects emojis to work and look roughly the same as on
| Apple's platforms, which means detailed multi-colored layered
| vector shapes that SDF font renderers can't handle.
| esperent wrote:
| The solution I've used for this, which was a bit tedious
| but not that hard to implement, was sprites for the
| icons/emojis and SDF for everything else. I'm sure there
| would be other solutions too, like layering. So it's not
| useless, you just need to get creative to overcome the
| limitations. Like everything else in 3D graphics.
| pavlov wrote:
| Yes, I agree -- I did write "useless on its own" to
| highlight that you need to extend the SDF rendering model
| with a different one to handle actual user-generated
| text.
| unconed wrote:
| Use.GPU handles this just fine: it uses a subpixel SDF mask
| with a plain color image. You get crisp edges, just the
| interior is a bit blurry.
| jkcxn wrote:
| If you have a couple of different sizes of texts you can render
| out each character into a sprite map and render a quad per
| character which is probably the fastest and works for most 2D
| UIs. You can prerender ahead of time or have some runtime code
| that renders the characters with a given font using the 2D
| canvas api. You will need also need to store the characters
| sizes somewhere unless it's a monospace font
|
| If you need to scale the text arbitrarily or render it in 3D
| space you can look at multi channel signed distance fields
| (MSDF) which also renders out each character but encodes some
| extra data which makes them scalable. It has pretty good
| results
| bhouston wrote:
| The easiest is just to use a html canvas element and draw text
| to it and then upload that as a texture map. This can handle
| kerning, ligatures, emojis, different fonts and languages.
| Writing your own font layout tool is horribly difficult and
| only do it if you must.
| softfalcon wrote:
| Most web games use the dom as a layer over top of the 3D canvas
| and then use 3D to 2D projections to align the elements. This
| allows you to use regular HTML and CSS for a lot of text
| elements.
|
| Also, you can render and rasterize fonts + dynamic text to a
| texture and UV map it to a quad in 3D space if you need to.
| This is pretty inexpensive and easy to do as well.
|
| Lastly, the most difficult but performant option is using a
| shader to compute the font rendering. This is basically moving
| the font raster from CPU to GPU and there are various shader
| examples for this in GLSL (popular shader format used by
| WebGL/OpenGL) that you can use.
| charcircuit wrote:
| This doesn't work for webxr.
| jesse__ wrote:
| From personal experience, if you're trying to make a game
| that cares about its frame rate, do not ever use the DOM for
| anything, ever. It routinely takes several frames to layout a
| single absolutely positioned element.
|
| I recommend the second option. Rasterize your font with
| stb_truetype to a bitmap, and draw quads yourself
| depressedpanda wrote:
| I'm curious, isn't something like a HUD a perfect thing to
| render in a DOM overlay?
|
| It shouldn't matter that much if it takes a few frames to
| layout and/or update your ammo count or whatever.
| raphlinus wrote:
| One of the most exciting features of WebGPU, especially over
| WebGL, is the ability to run compute shaders. That opens up an
| entire class of 2D vector graphics rendering techniques using
| compute shaders, including Vello. It's still in early stages,
| but the current code _does_ include text rendering. There 's a
| very rough demo at https://levien.com/vello-demo (the demo
| doesn't do variable fonts but the code can), and we'll be
| polishing that in time for Chrome M113 going stable.
| pjmlp wrote:
| Thanks to Google blocking WebGL compute shaders adoption.
|
| We could have had them three years ago.
| CSSer wrote:
| Interesting. Do you have any more context around this? It
| sounds uncharacteristic of Google to do so given their
| usual stance on browsers being all things to all people.
| pjmlp wrote:
| Yes,
|
| https://registry.khronos.org/webgl/specs/latest/2.0-compu
| te/
|
| https://github.com/9ballsyndrome/WebGL_Compute_shader
|
| And then Google decides not implementating it after all,
| because of WebGPU.
|
| https://github.com/9ballsyndrome/WebGL_Compute_shader/iss
| ues...
| fulafel wrote:
| There's a lot of literature about font rendering predating
| compute shaders too, compute shaders are not a functional
| prerequisite by any means.
|
| Here's eg one case: https://github.com/astiopin/webgl_fonts
| pjmlp wrote:
| Yeah, that as well.
|
| WebGL 2.0 is kind of PlayStation 3 like in capabilities,
| that we seldom see that in action besides shadertoy,
| Google Maps/Earth, and 360deg views on ecommerce sites is
| another matter.
| dist-epoch wrote:
| > Do I vectorize it and draw millions of tiny triangles to
| approximate those vectors
|
| That is becoming feasible, using something called mesh shaders.
| The millions of tiny triangles will only be created on the fly
| inside the GPU, you will just send the vector geometry.
| raphlinus wrote:
| This is true, but there is a lot more to the story. For one,
| WebGPU does not (yet) support mesh shaders, though it may
| later as an extension. For two, consider a glyph such as "o"
| that has two contours. Real triangulation generates a mesh
| that only generates triangles between the outer and inner
| contours, and mesh shaders aren't good at that. There _are_
| techniques compatible with mesh shaders (cover and stencil)
| that draw twice, incrementing and decrementing a winding
| number stored in the stencil buffer (see contrast renderer[1]
| for a clean modern implementation), but it does require
| nontrivial tracking on the CPU side, and can result in lots
| of draw calls to switch between the cover and stencil stages
| unless sophisticated batching is done. (The outer contour is
| drawn as a disc with winding number +1, and the inner contour
| is drawn as a smaller disc with winding number -1, so the
| inner part ends up as 0)
|
| Compute shaders avoid all these problems and work on WebGPU
| 1.0 today.
|
| [1]: https://github.com/Lichtso/contrast_renderer
| dist-epoch wrote:
| > Real triangulation generates a mesh that only generates
| triangles between the outer and inner contours, and mesh
| shaders aren't good at that.
|
| I'm a bit confused. Can't you send the shape of O as a low
| res rough band (a closed wide loop) and enhance it in the
| mesh shader? This is how previous generation tessellation
| shaders and sub-division surfaces worked.
| raphlinus wrote:
| You might be able to do something along those lines, but
| I know of no font / vector 2D renderer that does so.
| There is a lot of literature[1] on this, so I suspect if
| doing things similar to subdivision surfaces were viable
| for font rendering, it would have been explored by now.
|
| [1]: https://2d.graphics/book/gpu_rendering.html
| bobajeff wrote:
| You could convert the paths in a font file into a series of
| triangles using some vertices as a control points for quadratic
| bezier curves. Then some code for laying out the glyphs in a
| line. Much of this could be done on a shader I think.
| rastette wrote:
| [flagged]
| baalimago wrote:
| Highly unavailable still, but it seems to be non-experimental in
| chrome 113-115, as of writing this
|
| https://caniuse.com/?search=webgpu
| doodlesdev wrote:
| Support should land in stable in 11 days
| billti wrote:
| This looks heavily geared towards graphics. I'm interested in the
| compute capabilities of WebGPU to build an in-browser simulator
| (e.g. physics/quantum). Anyone know of any good resources for
| that? (Samples, best practices, etc.)
| qz_kb wrote:
| This is usually done with shaders and a circle of buffers which
| maintain state.
| superzamp wrote:
| Total graphics / shaders / GPU noob here. Does that mean
| you'll essentially get free visualisations (albeit non-
| sensical ones) as a byproduct of your computations?
| jesse__ wrote:
| I think it depends, but given an arbitrary compute
| pipeline, you should be able to write the results (or
| intermediary results) to the screen with minimal effort.
| sva_ wrote:
| No, it's an @compute shader rather than a combination of
| @vertex and @fragment shaders (which would do graphics) in
| the case of WebGPU.
|
| Surely you could visualize it but not as a side effect.
| sritchie wrote:
| I think Steven Wittens's work at acko.net and
| https://usegpu.live/ is your best bet here. I've been working
| for a couple of years on building a computer algebra / physics
| system in Clojure and integrating it with Steven's previous
| work on MathBox, with some in-progress demos like this:
|
| https://emmy-viewers.mentat.org/dev/examples/simulation/quar...
|
| https://emmy-viewers.mentat.org/dev/examples/simulation/toro...
|
| Use.GPU looks like it will be close to a drop-in replacement
| for MathBox, running on WebGPU. Maybe someday I'll actually be
| able to build my general relativistic ray tracer, with
| explorable symbolic physics all the day down...
| sva_ wrote:
| It is sad that WebGPU has pretty poor support under Linux
| apparently. Even more so, that it builds on Vulkan which isn't
| fully supported on older architectures (like Haswell.)
| MrResearcher wrote:
| It's a pity that tfjs never truly developed any decent ops. E.g.
| you need lgamma to implement the cap for zero-inflated poisson
| regression and tfjs simply doesn't have that:
| https://github.com/tensorflow/tfjs/issues/2011 Those guys simply
| dropped the ball on the floor, and the further framework
| development fizzled out. I tried to find if WebGPU could be a
| replacement, but it's very hard to find a good description of the
| API surface. MDN also doesn't seem to help much -
| https://developer.mozilla.org/en-US/docs/Web/API/WebGPU_API I
| really hope that one day I'll find something similar to pytorch,
| only in typescript. Tell me I'll live long enough to enjoy that
| day.
| catwell wrote:
| WebGPU does not play in the same league as tfjs, it is a
| successor to WebGL, the technology tfjs is implemented with.
| There is already a WebGPU backend for tfjs:
| https://www.npmjs.com/package/@tensorflow/tfjs-backend-webgp...
|
| There are also several ONNX runtimes using WebGPU in case you
| want to run models written with PyTorch.
| MrResearcher wrote:
| Exactly, the lack of the deep learning frameworks to train
| decent models on the client side forces us to use pytorch on
| the server, leading to centralized data collection, privacy
| concerns, copyright and data ownership issues.
|
| Imagine the world where you could trivially train a model
| entirely on the client side, without uploading all that data
| to the cloud. Then we can settle on federated learning or
| simply use ensembles of models trained on different clients,
| all without sharing data with the server.
|
| BTW, I did have some experience with ONNX, also ran into
| problems with some ops (like nn.SELU not working correctly in
| the browser - https://pytorch.org/docs/stable/generated/torch
| .nn.SELU.html...).
| roschdal wrote:
| I have been trying to add WebGPU support to https://www.fciv.net
| - however the Three.js 3D engine I'm using isn't ready for WebGPU
| yet, and no current browsers support WebGPU yet.
| esperent wrote:
| The Three.js people have been working on WebGPU support for
| several years now. I'm not how far they've got but there were
| already some cool demos a year or more ago.
| upchuck540 wrote:
| works for me
|
| https://threejs.org/examples/?q=webgpu
| charcircuit wrote:
| Chrome supports webgpu on desktop.
| xchkr1337 wrote:
| Right now it's in beta (Chromium 113), stable support is
| planned for 26th of April
| rvz wrote:
| Yet once again, Firefox is behind, with WebGPU being non-
| existent. Chrome on the other hand is going to have support for
| it this month.
|
| Firefox is always behind and even if they catch up, their support
| is weaker than Chrome's.
| kllrnohj wrote:
| Firefox has support it's just behind a flag as the spec is
| still a work in progress draft. Which is what chrome is
| _supposed_ to do, too, but these days chrome doesn 't really
| care at all about standards and compatibility, instead they
| just want to be first to market ASAP because it's critical for
| CrOS capabilities
| flohofwoe wrote:
| Eh, AFAIK the WebGPU teams for Chrome, Firefox and Safari have
| been working closely together. Neither Firefox nor Safari are
| first, but I don't expect them to be much behind either.
|
| And as far as Chrome is concerned: WebGPU support for Android
| "isn't existent" either so far, currently it only works on
| desktop.
| illiarian wrote:
| > Neither Firefox nor Safari are first,
|
| WebGPU is literally built in top of work done by Safari and
| Firefox.
| flohofwoe wrote:
| Apple and Mozilla were the first to have prototypes (one
| "inspired" by Metal, the other by Vulkan), both looked
| quite different from the final WebGPU spec though.
| illiarian wrote:
| --- start quote ---
|
| On January 24, 2017, Khronos hosted an IP-free meeting
| dedicated to discussion of "WebGL Next" ideas, collided
| with WebGL working group meeting in Vancouver.[8] Google
| team presented the NXT prototype implementing a new API
| that could run in Chromium with OpenGL, or standalone
| with OpenGL and Metal. NXT borrowed concepts from all of
| Vulkan, Direct3D 12, and Metal native APIs. Apple and
| Mozilla representatives also showed their prototypes
| built on Safari and Servo correspondingly, both of which
| closely replicated the Metal API
|
| --- end quote ---
|
| (Note: Unlike Chrome, Apple and Mozilla followed the
| actual standards route: two independent implementations)
|
| --- start quote ---
|
| On February 7, 2017, Apple's WebKit team proposed the
| creation of the W3C community group to design the API. At
| the same time they announced a technical proof of concept
| and proposal under the name "WebGPU", based on concepts
| in Apple's Metal.
|
| --- end quote ---
|
| And so on https://en.wikipedia.org/wiki/WebGPU
|
| Apple is literally at the forefront of this entire
| initiative with Mozilla close second. Chrome grudgingly
| agreed to join the others a full year later.
| kvark wrote:
| This isn't correct. All 3 parties had prototypes.
| Mozilla's first prototype was based on Metal and
| implemented in Servo. Then we (Mozilla) proposed a
| Vulkan-like API and had another WIP in Servo, but it was
| also thrown out.
| dist-epoch wrote:
| The writing is on the wall. Firefox will ditch it's engine and
| just become a skin over Chrome, just like Edge did.
| EntrePrescott wrote:
| While I strongly doubt that, I'll still add the end of the
| joke:
|
| ... and Mitchell Baker will fire all of Mozilla's engine
| developers and use the money saved by that to give herself
| another multi-million dollar salary raise.
|
| https://en.wikipedia.org/wiki/Mitchell_Baker#Negative_salary.
| ..
| kvark wrote:
| Gecko engine looks pretty healthy to me overall. And WebGPU
| in particular is the least of a concern, given that Firefox's
| implementation is based on wgpu [1], which has great
| community and a lot of users within and outside of Rust
| ecosystem. I'm confident Firefox can ship it soon (tm).
|
| [1] https://github.com/gfx-rs/wgpu
| pjmlp wrote:
| At least Edge does offer additional browser features for OS
| integration and extended developer tools.
| bhouston wrote:
| To see the spreading support for webgpu check out
| https://web3dsurvey.com
| capableweb wrote:
| Unfortunately no source published as far as I can see. Would be
| handy to have available + issue tracker.
|
| Since you seem to be the one responsible, I'll write my
| feedback here instead of a issue tracker:
|
| It shouldn't recommend hot-linking the script, but rather to
| include the script into your project (or at least include a
| Subresource Integrity attribute so it doesn't change
| unexpectedly). Also feels like it's unnecessarily minified as
| it's so small, hardly makes a difference in payload size, but
| makes it a lot harder to review.
| bhouston wrote:
| I purposely didn't mangle the collection script. You can read
| it easily with all original variable names. Just format it
| which many browsers do automatically these days. I did this
| so you can verify its behavior.
|
| I can add a npm package as well so people can embed the
| collection script as well.
|
| I will also add an integrity check as well.
| thewebcount wrote:
| > It is expected you already know JavaScript before you read this
| article. Concepts like mapping arrays, destructuring assignment,
| spreading values, async/await, es6 modules, and more will be used
| extensively.
|
| So in other words, it's just like Vulkan where the beginner
| tutorials have you set up your own allocators, deal with fencing,
| and use a swap chain just to put a single triangle on the screen?
| What the actual fuck? This doesn't sound at all like
| "fundamentals" and makes me not want to ever use it if the very
| basics require all of the above. I think your average programmer,
| even one who does 3D graphics, is going to look at this and just
| be turned off.
| waboremo wrote:
| Most of those concepts are foundational to web programming,
| yes.
|
| I also believe that for most people who "just want a triangle
| on the screen" they'll be utilizing other higher level tools to
| do so, and those tools will then do the "dirty" work of using
| WebGPU. Think, Figma making it easy for people to design but
| behind the scenes it's incredibly complex using C++ (might be
| outdated on this) compiled to WebAssembly.
|
| Same will apply here, most people who want lower level access
| to the GPU aren't really doing so just because of simple
| triangles or basic graphics work. There are already engines and
| frameworks for them.
| shepherdjerred wrote:
| This is a beginner tutorial for WebGPU, not JavaScript. It's
| entirely reasonable to assume knowledge of language features.
| mpldr wrote:
| Question for discussion: when have we reached the point where the
| Browser Feature-creep is too much and we say "okay, a browser
| probably doesn't need this"? Because after seeing WebUSB and
| WebGPU I think my personal limit has been reached.
| cjbgkagh wrote:
| I think of the browser as another kind of OS, and as Microsoft
| keeps making their OS worse the browser is a nice reprieve. The
| more that goes into the browser the more I can ditch Microsoft
| and hopefully be rid of it all together.
|
| Though ironically maybe given that the browser can do so much
| is the reason that Microsoft has to focus on 'value add' crap
| instead of just a rock solid OS. Which sets up a self
| reinforcing cycle. Microsoft should recognize that this was
| intentional move by Google and not take the bait.
| [deleted]
| fatneckbeard wrote:
| WebPSU - this will allow your browser to directly access your
| computer's power supply. simply plug your appliances into your
| browser and they can use the same power that your computer has
| access to.
| jillesvangurp wrote:
| Who's the royal we here? It's great that you have personal
| limits. But why should "we" care about those?
|
| Seems like a perfectly reasonable new feature to me. I'm
| actually looking forward to people using this to build some
| cool stuff. Why should that not be a thing?
| saiojd wrote:
| Why does it bother you that browsers have many features? At
| this point browsers are essentially a cross-platform VM and it
| really seems like this trend will only accentuate in the
| future.
| 2h wrote:
| because I want limited scope tools. if I want something on
| the GPU, I can just write a native tool. I dont need the
| browser to do anything beyond web browsing.
| jazzyjackson wrote:
| well you should have no problem implementing your own
| static web browser then, why complain about the binaries
| others are running?
| IlliOnato wrote:
| Whatever features browsers have, it does not prevent you
| from writing native tools.
|
| But browsers don't limit themselves to serving your needs
| only, and they are not in the business of promoting your
| approach to computing among their users. Why would they?
| Dalewyn wrote:
| At some point we're going to have to drop the pretense of
| running an operating system underneath because the browser is
| the operating system.
| [deleted]
| mpldr wrote:
| Blink is my operating system and Linux is its bootloader.
| chris37879 wrote:
| How's chromeos treating you?
| mpldr wrote:
| https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=chromium
|
| https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=chrome
|
| https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=firefox
|
| https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=webkit
|
| Those are the main reasons. And seeing how browsers are
| essentially designed to run other peoples code with minimal
| to no vetting processes, I consider this a serious issue.
| saiojd wrote:
| Thanks for sharing, that's interesting angle that I did not
| consider. So essentially the argument goes that more
| "surface area" == more vulnerabilities? While that makes
| perfect sense, don't you feel like the pressure for more
| feature comes from somewhere? By analogy, dynamic languages
| like JS/Python make the job of people writing the compiler
| much, much harder. But, on the whole and despite all their
| flaws, it is true that they increased productivity by a
| lot.
| kajaktum wrote:
| So how is this any different if we don't have a browser?
| People still want to visit "websites" which in your world
| is even worse. Because now every website is a distinct
| application (yikes!). The problem is that people are
| willing to run arbitrary code in the first place.
|
| How many times have _you_ as a developer, run arbitrary
| scripts from the internet? Blindly accepts packages that
| you have not vetted?
| shrimp_emoji wrote:
| Too many to count.
|
| Remember Flash? ;)
| mpldr wrote:
| I would be very different if browsers were tools to view
| documents though. I am not saying that browsers don't
| have a purpose. I just question that browsers should
| answer the question about what their scope is with a loud
| "yes!"
| viraptor wrote:
| https://www.yubico.com/support/issue-rating-
| system/security-...
|
| Every new feature is more space for security issues to exist.
| capableweb wrote:
| > Because after seeing WebUSB and WebGPU I think my personal
| limit has been reached.
|
| Sure, but where do you draw the line really? For me, having
| WebUSB and WebMIDI for example is useful, I want to be able to
| interact with synths over MIDI in the browser, or be able to
| access other accessories. I also love the idea of GPU access,
| so my personal limit has not been reached.
|
| Multiply this by every vendor, developer and user of every
| browser who contributes to the specifications, and you end up
| with probably 1000 different directions everyone wants to move
| in. How do you decide which is the right direction?
|
| Right now, the choice you have is which browser you use. If you
| don't want WebUSB or WebGPU or anything else "new and fancy",
| choose a browser that doesn't implement those things.
| earthling8118 wrote:
| I'm not going to argue against these features, but I find
| that last argument you raise to be a rather dull and useless
| one. Yeah, I'll just go ahead and pick from one of the
| hundreds of competing implementations to find one that
| doesn't. Oh, wait, they don't exist.
|
| It's like saying "if you don't like the laws(/taxes/whatever)
| where you live, go somewhere else" and acting as if I can
| just hop on over to Mars. I can't.
| 1066 wrote:
| That is exactly what they are saying. Having control over
| your relative experience is the only thing people want.
|
| As we all spend most of our time inside of browser
| interfaces its not a surprise we see app, features and
| interfaces move to that process portal to. (Online IDEs,
| Cloud, Photo editing, etc.) Sure you can use your solution
| but in general, as always, its whats most efficient for the
| masses.
| boredemployee wrote:
| Tangentially in the WebMIDI topic, I wonder how DAWs will
| react with things going to browser and generative audio
| scaling quickly.
| reaperducer wrote:
| _I want to be able to interact with synths over MIDI in the
| browser_
|
| Help me understand why this is. Is it because there aren't
| native programs for the platform you're using? Is it to allow
| plug-ins or other abilities that wouldn't otherwise be
| available? Is it so that you can sync up with other musicians
| and play together in a way that wouldn't be possible without
| a browser?
|
| _choose a browser that doesn 't implement those things._
|
| The way feature creep have been going lately, in about six
| months that will mean Lynx.
| tiagod wrote:
| Because it's really cool to try out experimental
| instruments other poeple have made by simply opening a
| webpage, without having to execute untrusted native code
| that could have bad consequences.
| 2h wrote:
| AKA laziness. yes, lets please bloat of the scope of
| browsers until they are no longer recognizable, so that
| you dont have to install some software.
| andresgottlieb wrote:
| You oversaw the untrusted part, this is the only reason I
| prefer web over native really. If there was a way to run
| native apps with that level of isolation, I would prefer
| native.
| pjmlp wrote:
| Snap, Flatpack, iOS sandbox, Android sandbox, UWP/Windows
| sandbox,...
| wpm wrote:
| Instead, you're executing untrusted browser code, which
| is hardly better.
| galangalalgol wrote:
| I'm interested if this is true. It seems like the js
| sandbox is pretty well implemented now in most cases.
| Webgl had some problems at first leaking host data, but
| the willingness to sacrifice performance for security
| seems pretty ingrained in these consortiums?
| akarlsten wrote:
| I don't understand how you can possibly say this with a
| straight face.
| capableweb wrote:
| > Help me understand why this is. Is it because there
| aren't native programs for the platform you're using?
|
| Easier to create, easier to share and run. Mainly easier to
| create because the ones I'm sharing small MIDI sequencer
| experiments with are also web developers, so we just send
| each other links where we can run stuff direction from, and
| we can help each other out as we all use the same
| technology. Really easy to understand what the other is
| doing too, as you just open up the source of the page and
| that's it.
|
| I've played around with other languages/runtimes for doing
| the same thing, but nothing is as fast to implement as with
| JavaScript, probably mostly due to familiarity.
| kajaktum wrote:
| Browsers are just "standardised" OS at this point. Really,
| what is the difference? It seems to me that people basically
| wants a 1 to 1 mapping between every OS feature to browsers.
| I wouldn't be surprised if this standard will fall apart in
| the next decade once Chrome runs everything. That is to say
| Chrome is the standard. I am already seeing websites drop
| support for Firefox and won't even load using it.
| skybrian wrote:
| Even if Chrome were the standard, there would still be
| variety due to plugins. A lot of sites have glitches in
| Chrome too, if you install the wrong plugins or turn stuff
| like third-party cookies off.
|
| I'm not sure I trust people who say something doesn't work
| in Firefox, unless they tried it in a fresh profile with
| default settings.
| cleanchit wrote:
| > I am already seeing websites drop support for Firefox
|
| Examples?
| whitemary wrote:
| The Honda Financial website is Chrome-only.
|
| https://honda.americanhondafinance.com
| adwn wrote:
| Firefox 112 doesn't seem to have any problems rendering
| it. What do you mean by "Chrome-only"?
| kajaktum wrote:
| I mean it doesn't do any QA on them. My banking website
| won't load on Firefox for example.
| Kiro wrote:
| What's your bank considering we still haven't been given
| an example? The Honda one works fine in Firefox.
| ptato wrote:
| I've found enough Firefox-only bugs when doing things
| through spanish government sites that I started using
| Chrome for them preemptively.
| zawaideh wrote:
| Snapchat web
| MikeSchurman wrote:
| I'm not sure if these are examples of dropped support,
| but I run into issues on websites that prevent me from
| doing something I really need to do: - I could not
| unsubscribe from amazon prime yesterday using firefox.
| The page where you select the option was not rendering
| correctly. It was white for half the page vertically and
| the link/button I need to press was absent. - about 6
| months ago I could not sign into apple id on apples site
| on firefox. (or something like this, I forget exactly
| what I was trying to do). - about 6 months ago I could
| not sign into nintendo's site to cancel a subscription.
|
| So it's not super frequent, but every few months there
| are important things I can't do in firefox.
| javajosh wrote:
| Firefox has a better plugin ecosystem, and it's plugins
| that cause a lot of site issues.
|
| It's a very clear trade-off in the hands of the user,
| which is correct.
| galangalalgol wrote:
| Yeah, with one exception it has always been dark reader
| that caused a page to render wrong in Firefox. The
| exception was some misconfigured oauth stuff that didn't
| work.
| tourgen wrote:
| [dead]
| ReptileMan wrote:
| The more of this features in the browsers - the sooner the
| stranglehold of the app stores could be broken
| SquareWheel wrote:
| I tend to feel that way mainly towards new features that are
| very similar to ones that already exist. eg. WebGPU being a
| more advanced form of WebGL. Yes they work differently, but
| they generally solve the same problem.
|
| Eventually I'd like to see WebGL deprecated, and perhaps an
| extension released to reimplement it. Or it could be adapted to
| translate calls to WebGPU, rather than having a completely
| separate implementation.
|
| Is that realistic? No, of course not. Browser vendors take
| backwards compatibility pretty seriously, and WebGL is used on
| a ton of websites. Still, that'd be my preferred solution for
| avoiding said feature creep.
| moron4hire wrote:
| That's actually not unreasonable, as WebGL under the hood is
| already implemented through Vulkan, Metal, and DX12.
| Cloudef wrote:
| WebGPU in browser isn't really interesting to me. But I do like
| WebGPU in native applications, as we are yet again in scenario
| where Windows prefers DX, OSX their own Metal and Vulkan is yet
| again mostly linux only player, and popular WebGPU
| implementations have backends to all of these (+ more).
| jesse__ wrote:
| Why exactly would programs running in web browsers not want the
| ability to access the most powerful piece of hardware in a
| users machine? WGPU unlocks an enormous amount of space for
| userland programs to explore.
|
| I agree there have been some questionable 'advancements' in the
| web spec recently (web workers as a solution to multithreading,
| for example, were hilariously inadequate for quite a while),
| but as far as I can tell WGPU is a solid effort to unlock
| browsers as an actually interactive platform, instead of the
| fairly static image/text display devices they are today.
|
| Maybe our visions of what browsers could or 'should' be are
| different
| mpldr wrote:
| At least for me a browser should be an interactive document
| viewer. Not CAD, not file conversion, not writing OS images
| to an SD card, not generating GCode. Ingesting HTML, CSS, and
| JS and turning it into an interactive view of that XML
| document nothing more, nothing less.
| throwaway60134 wrote:
| [dead]
| CapsAdmin wrote:
| It will stop once it's easier, more reliable and more secure to
| run someone's code outside your browser.
| [deleted]
| hathawsh wrote:
| I think one of the main drivers of new browser features is
| ChromeOS. Manufacturers are selling a lot of Chromebooks,
| especially to schools, and because ChromeOS is primarily a
| conduit for running Chrome, the best way to add features to
| Chromebooks is by adding to the browser. From Google's point of
| view, anything ChromeOS needs is a candidate for a new browser
| feature.
| [deleted]
| RGamma wrote:
| Free yourself from the notion that a web browser purely browses
| The Web.
|
| It's nowadays also a cross-platform insta-deployment GUI
| application runtime environment with mostly bad native OS
| integration and performance characteristics (both ~improving,
| there's even native filesystem access now).
|
| In any case it's Good Enough (C), so it sticks.
| danielvaughn wrote:
| there's native filesystem access?
|
| edit: wow, I had no idea and I've been a web dev for over a
| decade lol
| 2h wrote:
| > Free yourself from the notion that a web browser purely
| browses The Web.
|
| Free yourself from the notion that a web browser should do
| anything more than browsing the web. native applications have
| existed for decades, no reason to bloat the scope of a
| browser.
| shpx wrote:
| One big reason is that installing the software is one click
| (on the link) and it works every time. With native
| software, on phones you have to open the App Store, search
| for an app and usually wait to download hundreds of
| megabytes before anything happens. On personal computers
| it's much worse.
| IlliOnato wrote:
| Hmm, RGamma describes reality: it is a fact that web
| browsers don't purely browse The Web, has been for decades
| now, and there is zero indication this is going to change.
|
| You seem to demand that people ignore this reality, because
| you don't like it. This is not helpful.
|
| I don't like this reality either, but despite that I find
| your statement also factually incorrect: "native
| applications have existed for decades, no reason to bloat
| the scope of a browser".
|
| Of course there are reasons, otherwise people/companies
| won't do it, and users won't use bloated browser that give
| them no benefits.
|
| I agree that downsides outweigh the upsides, but the
| upsides are obvious and immediate while the downsides are
| long-term and mostly subtle...
| [deleted]
| RGamma wrote:
| I wish it wasn't true either.
|
| Seeing a semi-technical acquaintance use in-browser
| software for daily productive work hurts my programmer's
| soul. It's alright for some light things, like vacation
| planning, but remote desktop or an IDE...
|
| Then there's that other scourge of Electron-like apps with
| gigantic memory budgets and all. I have resigned to
| throwing more hardware at it when I can't guarantee a
| lighter replacement (i.e. in a work setting):
|
| All my productive systems have 32GB RAM and 8+ threads now
| and with browser, Teams, Outlook, IDE and dev containers
| the air's getting thin again :/
| mpalmer wrote:
| In the age of app stores and notarized binaries, anything that
| makes the browser non-trivially more competitive with native
| apps is defensible.
| magicalhippo wrote:
| WebUSB was actually useful to me not long ago. I installed Home
| Assistant and its ESPHome[1] companion, and ESPHome had support
| for using WebUSB to upload the firmware to a blank ESP8266 I
| had. I didn't have to install or set up anything on my Windows
| machine, and the whole process was very quick and convenient.
|
| It seems clear to me that the main issue here is that a lot of
| programs aren't closely tied to the hardware or the OS.
| Building them to be so is an annoyance for both users and
| developers. As Scott McNealy said, you don't need to know how
| to operate a nuclear power plant to turn on the lights, and
| most users just want to get stuff done.
|
| That we have three major operating systems still going
| relatively strong is evidence that there are differences that
| matters to people. But for a lot of applications those
| differences don't. The WebXYZ stuff thus increases usability a
| lot by simultaneously solving the cross-platform compatibility
| issues and distribution.
|
| In my ESPHome example above literally opened the website,
| plugged in the USB cable to my device, clicked a button on the
| web page and the job was done.
|
| So while I don't really like that the same web browser is used
| to surf other web sites, given that these WebXYZ components
| present additional security risks and fingerprinting
| opportunities, I can't deny that they're useful.
|
| [1]: https://esphome.io/guides/getting_started_hassio.html
| awhitty wrote:
| I had a similar pleasant experience with a Wooting 60HE
| keyboard I purchased recently. Updated my keyboard's firmware
| and settings right in Chrome! So much nicer than downloading
| icky gaming peripheral software. I've been told a lot of that
| stuff is borderline spyware.
|
| Excited to try it out with some ESPHome projects too now.
| jimmySixDOF wrote:
| But the web is where the stuff I want is. Just about everything
| else gets in the way.
| dvngnt_ wrote:
| I don't see a problem you don't have to use it
| chii wrote:
| the more important question is whether the browser's surface
| area for bugs and perhaps security vulnerabilities are worth
| the marginal increase in features that most people might not
| use!
| abirch wrote:
| You can find a security focused browser that don't
| implement these.
| mpldr wrote:
| Please, let me know which one!
| throwaway60134 wrote:
| [dead]
| moron4hire wrote:
| It's not like native OS features don't have security
| vulnerabilities. At least all the major browser have at
| some major portion of their implementations that are open
| source projects. So if you're stuck working on Windows or
| MacOS, at least you can know that Web browsers aren't
| limited to one vendor finding and fixing those defects.
| archerx wrote:
| I used webUSB to make an NFC login system and it was awesome,
| what's the problem?
| gary_0 wrote:
| The issue of the Web's lack of distinction between document
| viewing features and being an application platform (with access
| to system resources and private data) is decades old.
| Unfortunately, the question has been academic for decades as
| well: before the advent of HTML5, proprietary browser plugins
| gave Web sites the same abilities (ActiveX and Flash being
| notable, as were their security vulnerabilities). Flash was
| ubiquitous circa 1998-2008; your typical user would always have
| it installed. Nor did the typical (non-techie) user know that
| the Web was not originally intended to be an application
| platform, or the implications of it being used as such.
| z3t4 wrote:
| The browser is basically an OS ontop of an OS ontop of. ..
| turtles all the way down
| CyberDildonics wrote:
| _The browser is basically an OS ontop of an OS ontop of. ..
| turtles all the way down_
|
| The OS runs on hardware, what do you think is below the OS
| you're running?
| krylon wrote:
| Intel has its ME which last I heard runs Minix, AMD has the
| PSP, though I don't know what kind of software that runs.
| reaperducer wrote:
| _The OS runs on hardware, what do you think is below the OS
| you 're running?_
|
| Even excluding VMs, there are a lot of OSes running in a
| modern computer. Some chips have their own. BIOSes and
| Secure Enclave, networking chips, and probably a dozen
| more.
| CyberDildonics wrote:
| Try to understand the context of more than one comment at
| a time if you can. This person said _" it's turtles all
| the way down"_ because there are two layers, the browser
| and the OS, which is ridiculous.
| reaperducer wrote:
| _Try to understand the context of more than one comment
| at a time if you can._
|
| Try not to be a condescending dickweed, if you can.
| inportb wrote:
| I think WebCPU is where it's at. First class virtualization in
| the browser so you don't have to emulate :)
| pmoriarty wrote:
| Can this somehow be leveraged to crowd-train LLMs or maybe do
| something like SETI@home within the browser?
| icedrift wrote:
| From what I understand not at this time but potentially in the
| future with different algorithms. DL training requires long
| sequential computations that can't be done in parallel the way
| folding at home could.
| wongarsu wrote:
| No, distributed training is one of these holy grails nobody has
| quite figured out yet. You can split training across multiple
| GPUs in the same computer, or multiple computers in close
| proximity connected by infiniband, but that's about as much
| latency as we can handle right now. We need some breakthrough
| to make it possible for internet-connected computers to
| usefully collaborate.
|
| If it did work we wouldn't be waiting around for WebGPU, it
| would already exist as a desktop program.
| sgc wrote:
| Pardon my naivety. The only reason individuals would
| _willingly_ participate at a large scale, would be for an
| open source AI project. Does that mean once the problem is
| solved, everybody will likely be able to run their own state
| of the art AI, or are the real-time calculations too
| intensive for a single server?
| wongarsu wrote:
| As a reference point, the large version of facebook's LLaMA
| was originally designed to be run on 4 server-grade GPUs,
| but after it was leaked people managed to make it run on a
| normal computer with just a CPU and 40GB RAM or so, though
| it's somewhat slow when running that way. GPT 3 is about 3
| times larger than that. But at least for LLMs we have
| mostly explored how to either make really big models with
| the best capabilities (OpenAI etc) or models that are
| faster to train for comparable capabilities (facebook etc).
| There's comparative little work done so far on models that
| are able to run with the least amount of resources
| possible, though there are indications that you can invest
| more resources in training to get models that are much
| easier to run (training a small model for really long to
| get the same capabilities as a larger model). That might be
| a great route for an open source project, spending great
| combined effort to make something everyone can more easily
| run at home.
|
| Of course that's mostly LLMs, for image generation you can
| easily run Stable Diffusion on any somewhat decent GPU, and
| being able to collaboratively train better models might be
| a huge boon there too.
| pmoriarty wrote:
| What are the main obstacles they need to be overcome to make
| this a reality?
| archerx wrote:
| I wish they had kept the c/c++ syntax style for WGSL, the rust
| syntax is just awful and alienating.
| jeroenhd wrote:
| I much prefer the new syntax. The C based shader languages
| always end up in some kind of uncanny valley where it looks
| like C and C++ but behaves completely differently.
|
| It's not exactly Rust either, the @annotations aren't written
| like that in Rust for example.
|
| The let-syntax is closer to Javascript with type annotations,
| so that makes more sense for web programming than doing C style
| variable definitions. Using let and var instead of let and cons
| is a bit of a weird choice, though.
|
| Other than the variable definition syntax, this syntax may as
| well have been C++-based without all the verbose names that C++
| likes to add to its namespaces. Shades will usually mostly be
| math code, though, so it shouldn't even matter all that much in
| practice.
| hatuthecat wrote:
| Not sure how it remotely looks "awful and alienating". It looks
| like basically every recent language to me
| (swift/kotlin/rust/typescript). I feel like you just saw
| something that has the same numeric type names as Rust and
| jumped to conclusions.
| FL33TW00D wrote:
| Not if you're a rust programmer!
| Razengan wrote:
| Regarding all the arguments about ever-increasing browser
| complexity and the resulting inefficiency:
|
| Why is nobody asking the reverse question: How to make _operating
| systems_ more like browsers??
|
| From the end user's PoV (consider someone who isn't computer
| savvy) what are the _actual_ objective differences in usability,
| between the OS and browser?
|
| --
|
| * OS: Apps have their own windows and menu bars.
|
| * Browser: Multiple apps run in a single window, and have no menu
| bar.
|
| -
|
| * OS: Need to download and "install" apps before you can use
| them.
|
| * Browser: Just type the app's "name".
|
| -
|
| * OS: Need to make sure apps are compatible with your OS and
| hardware. Need to keep apps updated. Need to delete apps when out
| of local storage space.
|
| * Browser: Nope.
|
| -
|
| * Browser: Lets you share links with people to show them exactly
| what you're seeing in an app (YouTube, HN, Reddit)
|
| * OS: Nope.
|
| --
|
| SO. Instead of constantly reinventing the wheels that have been
| perfected by operating systems for centuries, and then
| machete'ing through the resulting struggles of power and politics
| between the OS and browser,
|
| WHY NOT REMOVE THOSE HURDLES FROM THE OS?
| jeroenhd wrote:
| All of this is perfectly possible. End users don't seem to want
| to use these features for native apps for some reason, though,
| and developers seem to have all switched to the web instead of
| building native experiences.
|
| It makes sense: native apps need to be developed for Windows,
| macOS, Android, iOS, and maybe Linux. Web apps need to be
| developed once. Android apps will work on Android, ChromeOS,
| Linux (after some setup), and Windows, but I doubt Apple is
| going to add an Android runtime to their platform any time
| soon.
|
| App stores are on every major platform and custom URIs for
| sharing app state and views are implemented on phones already.
| Most people seem to run their desktop applications either full
| screen or nearly full screen. Pin the Windows task bar to the
| top of the screen and you've basically got yourself a tab bar.
| I don't know about macOS, but Android and Windows will start
| clearing caches and temporary files automatically under storage
| pressure. Sandboxing applications is available on all platforms
| as well.
|
| I don't want every website to become a native application,
| though. I don't trust most websites enough to download native
| code from them. Let's not go back to the ActiveX/Java applet
| days where you needed to download some scary code for every
| website you wanted to visit.
|
| I don't see why I would benefit from WebGPU support, I think
| I'll leave it disabled by default. It's probably one of those
| technologies that'll be useful for platforms with overbearing
| control (i.e. how game streaming on iOS is made possible).
| Maybe some small itch.io games will make use of it so I don't
| need to download Some Guy(TM)'s native executable every time I
| want to try a small experimental game.
| pjmlp wrote:
| They already did, it is called app stores.
| lacasito25 wrote:
| one can hope that with web assembly we can get closer to that
| dream, and eventually just remove the whole web browser.
| jeroenhd wrote:
| .jar files exist and so far they haven't replaced any
| browsers as far as I can tell.
___________________________________________________________________
(page generated 2023-04-15 23:00 UTC)