[flagged]
The writing is on the wall. Firefox will ditch it's engine and just become a skin over Chrome, just like Edge did.
WebGPU Fundamentals
21–30 of 211 posts
Re: WebGPU Fundamentals
#22[flagged]
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.
> Neither Firefox nor Safari are first,
WebGPU is literally built in top of work done by Safari and Firefox.
Re: WebGPU Fundamentals
#23How 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.
> 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.
Re: WebGPU Fundamentals
#24Question 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
Re: WebGPU Fundamentals
#25To see the spreading support for webgpu check out https://web3dsurvey.com
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.
Re: WebGPU Fundamentals
#26Great resource, but this website really doesn't want you going back to previous page.
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
Re: WebGPU Fundamentals
#27Question 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.
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.
Re: WebGPU Fundamentals
#28How 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.
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.
Re: WebGPU Fundamentals
#29Earlier quoted context omitted.
Some people have been using signed distance fields (sdf) to define fonts on the GPU.
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.
Re: WebGPU Fundamentals
#30Question 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.
I don't see a problem you don't have to use it
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!