This was the major roadblock for WebGL2 acceptance of developpers looking to support all major browsers.
I once (4 years ago, sheesh) made a "Pure-JS, no-build-step-required Minecraft Thing": https://github.com/mrspeaker/webgl2-voxels
When I made it I needed to specify it "Requires ES6 modules and WebGL2 support." At the time I was sure WebGL2 was going to be widely available soon and that ES6 modules would probably never be supported!
For me, google.com is 1.47MB. It makes you wonder what they put inside.
We are using a WebGl plugin and recently it broke on Safari, we had to detect this new Safari version and downgrade the users to a 2D mode (it was a third party plugin so I can't debug it)
Latest Safari cannot be used by users who cannot run the latest MacOS on their hardware, or have reasons not to (such as bricking risk with latest MacOS on old hardware.)
(I imagine it's similar with iOS but I'm not sure.)
The iPhone 6s was released in 2015 yet can run the latest version of iOS released in 2021. It probably won't be able to run the 2022 version of iOS but at that point it will have been seven years. I'm sure Android can't be updated for that long, I don't know if a current browser for Android can be run on a seven year old version of Android.
https://en.wikipedia.org/wiki/Safari_(web_browser)#Safari_15
Yes it can - pretty sure my daughter's old Mac running Mojave got an update to the newest Safari a few days ago.
Does anyone know where these performance differences stem from?
[1] https://github.com/kakashidinho
[2] https://lehoangquyenblog.wordpress.com/2020/09/30/google-ope...
"Apple adopted ANGLE as the basis for Safari’s WebGL implementation, and as a result, their engineering team spent over a year making dramatic contributions to ANGLE’s Metal backend. Safari now runs WebGL on top of Metal on recent iOS and macOS devices. Collaborative work continues among the Apple and Google engineering teams, including adopting top-of-tree ANGLE into WebKit, creating a common codebase for development going forward, and switching Chrome to use ANGLE’s Metal backend as well."
MANGLE: ANGLE on Metal
VANGLE: ANGLE on Vulkan
SwANGLE: ANGLE on SwiftShader
DANGLE?: ANGLE on Direct3D - dunno if anyone's ever called it thatSo in 10 years, no browser vendor ever thought it was worthwhile improving their developer tools to support 3D developers.
Firefox did have a toy debugger that they eventually killed and that was it.
Maybe they are holding on webgpu. People are carefully optimistic in it becoming the one API to be actually cross-platform.
The state of tooling on Khronos APIs is just terrible, there is always this "community should do it" and naturally they are always a shadow of what commercial API SDKs offer in capabilities.
To the point that I think if Khronos was responsible for the Internet only IP would have been standardized.
- uniform buffer objects. OpenGL is limited to how many uniforms you can pass to each shader via glUniform* calls, making things that use a lot of uniforms (such as skeletal animation or instancing) effectively a no-go. Uniform buffers enable uniforms to use much much more memory.
- vertex array objects. Previously, you had to rebuild and respecify vertex attributes, in addition to actually pointing them to the right data, dynamically every frame. Vertex array objects capture all that state into one structure, which is usually built at the start of the program, so that it’s nothing more than a single pointer swap per-frame to render different kinds of models. It can be faster or slower depending on the hardware and driver but it’s faster for developers, at least.
- depth textures. Previously the depth buffer was pretty much write-only, making things like shadow mapping impossible without hacks like writing the z-coordinate to an extra color buffer off-screen.
- instancing. Now you can render many copies (‘instances’) of a model in just one draw call by passing a ‘count’ parameter, rather than making N draw calls. This is almost universally faster, where applicable.
I guess a big one outside of graphics is integer textures and bit manipulations. The rest seems like general built-in additions.
It unlocks a number of nice to haves over WebGL 1 which improve usability, quality and performance. As Safari was the last stand out developers can now rely on these things being there.
It's here now. WebGPU has been on the horizon for many years, and probably will be for several more before you can actually expect it to work on users browsers. Presuming we don't end up with a repeat of WebGL 2 on Safari.
It's simpler. Much like DX12, WebGPU is intended to be lower level and have better control over hardware. Which makes it more complex and harder to use Vs WebGL.
It has plenty of community knowledge from OpenGL ES peeps, which makes it quite easy to find examples that can be used.
For anyone actually building this style of content today, this is huge news.
> WebGPU is the working name for a future web standard and JavaScript API for accelerated graphics and compute, aiming to provide "modern 3D graphics and computation capabilities". It is developed by the W3C GPU for the Web Community Group with engineers from Apple, Mozilla, Microsoft, Google, and others. [1]
Additionally, with some careful coding you can already run WASM+WebGPU applications both natively (e.g. via wgpu-rs) and in the browser, so you can pick and choose the best tooling depending on your use case, so ultimately I guess that's going to be the way forward.
idk I'm shipping code that uses the Qt RHI which works on D3D, GL, Metal, Vk ... cross-platform enough for me.
EDIT: Chrome 98 also works on Android 6.
(That version range still seems quite restrictive though.)
HTML tags.
This is part of the problem with the world of computing today. When a software released not quite 2 years and 4 months ago is referred to with the phrase "all the way back". Don't get me wrong, I'm all for keeping things as up-to-date as is reasonable, but the industry has far too much churn in many areas.
The point is you'll never make more than a couple dollars even doing it at massive scale so nobody bothers whereas before there was enough incentive to actually do it.
Didn't you mean "an alternative to Google?"
Don't blame the tool for the (lack of) craftsmanship.
Web technologies lag behind desktop technologies for good reasons.
WebGL 2 is based on OpenGL ES 3, which brings it to rough feature parity with a fairly common baseline for GPU APIs that dates back to 2007-2008-ish, the OpenGL 3 / DirectX 10 feature set. This is a pretty good feature set.
The Metal ANGLE backend work done by Apple was a large chunk of work, but a lot of it needed to be done anyway to continue to support WebGL at all on Apple platforms given Apple's deprecation of OpenGL.
Not always true though.
The target hardware is different between the game industry and the web industry.
Games focus on delivering best graphics with the latest hardware, whereas websites should care about the compatibility first.
Even though modern web browsers auto update, it does not update the underlying hardware. That is, many non-latest smartphones that do not support Vulkan won't support WebGPU neither. We need to wait for years to safely use WebGPU.
There’s always someone in a browser tech thread that has to proclaim their security high ground to the unwashed masses.
In my opinion, these comments do not add value to the discussion and should avoided.
Specially since, I think, many of us would do it if it weren't so inconvenient. I wish websites could only run JS if they're "installed" PWA style.
To turn this on its head, if I'm creating a new product now, why invest time into an API where by the time the product would be ready with WebGL, instead I chose WebGPU, so now have the risks:
- The API is still years away from mainstream.
- Doesn't solve anything for my use case that wouldn't be solved with WebGL.
- Is too buggy to use on most configurations.
- Isn't supported by X hardware or Y OS.
- Has security issues that make browsers disable it for years.
- The code has to be regularly updated/maintained/fixed when browsers update.
- Performance could be lower for low end systems.
- Even if everything worked, it's a lot more work to do everything (e.g. VULKAN).
- To beat webGL, you have to optimise specifically for mobile/desktop/amd/nvidia/etc
- The documentation is poor.
- It's impossible to hire an expert in webGPU.
- It's very expensive to test every combination of GPU/OS/driver so you have no confidence it is working correctly.