To be clear, this article is triggered by the fact that Safari, the only major browser that did not support WebGL2, has landed support a few months ago.
This was the major roadblock for WebGL2 acceptance of developpers looking to support all major browsers.
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!
You got me wondering what was going on - 425Kb seemed pretty high. I imagined there would only be around 50K of non-compressed source code. Turns out the 200Kb+ culprit is the texture atlas I nabbed off the internet: https://github.com/mrspeaker/webgl2-voxels/blob/master/res/m... - I'm only using a handful of cells out of that, I should chop it!
You know what would be fun? Trying to program a bot to clear all the titles using the same interface as humans (WASD + Mouse + Vision). That could even be a competition.
Nothing at all - rewriting it for WebGL1 would be trivial (if you rely on OES_vertex_array_object being present). But really it was just me learning, and I naively assumed WebGL2.0 would be ready "any day now". The only non-supporting browser was Safari. That was 4+ years ago!
Thank you for sharing. Appears you did not pick a license - I'd recommend just releasing under MIT unless you have any particular preferences (it's a well-understood "do what you want" license that I believe is suitable for educational content).
This is excellent news.
For years it was the only major browser with no WebGL 2 support : Chrome and Firefox support WebGl 2 since 2017 ...
Most WebGL libraries have WebGL 1 fallbacks only to make apps run on Safari.
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)
It's worth bearing in mind that the Safari major version and OS version are tied together.
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.)
You have it backwards, there is no separate installation of Safari for iOS or iPadOS, it only comes as part of an OS upgrade. Major (named) macOS updates come with a new version of Safari but it is also available to install on the two previous major versions of macOS. The current version, macOS Monterey (v12), came with Safari 15 and Safari 15 is also available for macOS Big Sur (v11) and macOS Catalina (v10.15).
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.
The latest version of Firefox (97) at least claims to run on Android 5.0 which is from 2014. It runs fine on my Retroid Pocket which is on Android 6. So at the very least that's available.
This is not correct, you can update to the latest version of Safari on all supported versions of macOS. Currently, Safari 15 is available all the way back to macOS Catalina (from 2019...)
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.
2019 is _ancient_ in terms of web browsers... What you call churn is actually mostly moving the web platform forward and fixing exploits. There's no way for the modern web to work without the rapidity of development browsers are undergoing.
Pretty sure that's the OS we're talking about, macOS Catalina 10.15? I am running it right now, and not pining for the new shininess of the more recent OS releases. If it wasn't still getting security updates, sure (but I've got a few more months, at least).
For MacOS this is not true. You will get Safari stable decoupled from the operating system going back two versions (Catalina and Big Sur). What you cannot run is Safari Technology Preview, that is available only for the current OS version.
I’ve been developing in WebGL for the last year on a Mac and can’t help but notice that Firefox and Chrome have much better performance (fps) than Safari. I would’ve thought Safari on Mac hardware would work best.
Does anyone know where these performance differences stem from?
I think Le Hoang Quyen[1] deserves a shout-out for writing the initial implementation of ANGLE's Metal backend, which is now used to power WebGL in Safari. Impressive work! It looks like they got some recognition from Google already[2], which is nice to see.
It's cool that the work Safari team did will also help Chrome improve their implementation in the future. WebGL 2 enables a lot of great experiences (especially with AR and XR now becoming more of a thing).
"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."
Maybe. It's not like the market for native graphical debugging tools is overflowing with options either, which is why I didn't understand OP's point that well.
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.
WebGL was my first exposure to gpu programming - when I eventually wrote a D3D11 renderer I simply could not believe how much better the tools were. My advice to anyone wanting to learn graphics programming is to start with D3D, the debugging experience is at least 10x better, which makes the whole process so much less painful.
I did my graduation thesis porting a particle engine from NeXTSTEP into Windows using OpenGL, so you can imagine how long I follow OpenGL.
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.
As someone who’s worked with many different OpenGL versions the big things I noticed were ‘missing’ from WebGL 1.0 are the following (some were available as extensions, but they are now standard):
- 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.
Profit not revenue. Costs (or lackthereof) are irrelevant as the amount of profit is the amount of profit regardless of what factors led to that final profit number.
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.
I switched from uMatrix to medium-mode uBO. Sort of a middle ground between what uMatrix was and default uBO mode (known as easy-mode). They offer other options as well.
That doesn’t matter at all, I’m talking about investment. Why continue to develop the older API while a new one is already underway? Sorry I just think it’s a waste of time and resources. What is WebGL 2 going to give us that WebGPU isn’t promising to deliver?
Something that works now and will continue to work for years without changing any code.
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.
Most rendering code should abstract to many APIs anyway, so not starting with a webgl version would be quite insane.
I'm not talking about today though, my concern is more around future investment. The web has to be backwards compatible, meaning that years from now, browser vendors will be tasked with supporting WebGL 1, WebGL 2, and WebGPU. Given that browsers are already the most complex programs in the world, is the benefit of WebGL 2 so great that it's worth it?
Luckily that cost is fairly small, due to how bad GL drivers were on Windows ages ago Google initiated the LibAngle project that abstracted the GLES parts needed for WebGL(1&2) onto DirectX.
With much of the heavy lifting done for API support the code was then adopted as an abstraction for other low-level APIs, so iirc the recent WebGL 2 implementation that now bought us to this stage is also dependent on a fork of that lib that targets Metal. (And yes, it brings us a monoculture implementation but I'd rather have that than dozens of broken mainline OpenGL drivers from Intel, AMD and Nvidia).
They are not mutually exclusive, and organization can invest in developing both. WebGL also has the advantage that it’s immediately useful (lots of sites already using it).
It's "mature". So it's well understood, documented, used in libraries, has guides all over the place and relatively few bugs.
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.
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 way I see it, browsers are already API-bloated. I just don’t see the justification for further developing a graphics API when another one based on more modern standards is already underway. It’s not like it’s a small effort.
If it took 10 years to achieve widespread webgl 2 support it could take another 10 for webgpu. People want to make web applications today, not plan them for the future.
WebGL 2 was fully developed five years ago. What happened now was Safari finally exposed support, and reused a lot of implementation effort done by Google in the form of ANGLE (which Safari was already using, just not exposing WebGL 2). This was not a from-scratch implementation and development of a new API, it was a collaboration and adoption of an existing API shipped in all other major browsers for years.
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.
> OpenGL is being replaced across the industry by modern rendering APIs like Vulkan etc.
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.
> 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]
This was the major roadblock for WebGL2 acceptance of developpers looking to support all major browsers.