Live data from Hacker News

WebGPU Fundamentals

webgpufundamentals.org

51–60 of 211 posts

Re: WebGPU Fundamentals

#51
post #19

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.

The more of this features in the browsers - the sooner the stranglehold of the app stores could be broken

Re: WebGPU Fundamentals

#52
post #40
post #32

Earlier quoted context omitted.

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.

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]

Re: WebGPU Fundamentals

#54

Earlier quoted context omitted.

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…

> 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.

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

Re: WebGPU Fundamentals

#55
post #43

Earlier quoted context omitted.

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.

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?

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!"

Re: WebGPU Fundamentals

#56
post #50

Earlier quoted context omitted.

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'l…

Thanks to Google blocking WebGL compute shaders adoption. We could have had them three years ago.

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.

Re: WebGPU Fundamentals

#57
post #13

Earlier quoted context omitted.

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.

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.

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.

Re: WebGPU Fundamentals

#58
post #24
post #19

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.

The browser is basically an OS ontop of an OS ontop of. .. turtles all the way down

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?

Re: WebGPU Fundamentals

#59
post #50

Earlier quoted context omitted.

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'l…

Thanks to Google blocking WebGL compute shaders adoption. We could have had them three years ago.

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

Re: WebGPU Fundamentals

#60
post #19

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.

> 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 u…

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.

Post reply on HN