[HN Gopher] WebGL 2.0 Achieves Pervasive Support from All Major ...
___________________________________________________________________
WebGL 2.0 Achieves Pervasive Support from All Major Web Browsers
Author : nkjoep
Score : 202 points
Date : 2022-02-17 08:41 UTC (14 hours ago)
(HTM) web link (www.khronos.org)
(TXT) w3m dump (www.khronos.org)
| dezmou wrote:
| I hope if apple took all this time it's for implement the specs
| correctly this time.
| danielvaughn wrote:
| Why though? WebGL is already getting left behind for WebGPU.
| andybak wrote:
| https://caniuse.com/webgpu
| danielvaughn wrote:
| 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?
| stingraycharles wrote:
| 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).
| fizzynut wrote:
| 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.
| danielvaughn wrote:
| 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?
| whizzter wrote:
| 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).
| kbumsik wrote:
| The WebGPU spec itself is not yet confirmed AFAIK. Thus no
| browser has a stable support.
| danielvaughn wrote:
| Right...but OpenGL is being replaced across the industry by
| modern rendering APIs like Vulkan etc. Isn't WebGL 2 still
| based on OpenGL?
| klodolph wrote:
| So?
|
| 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.
| danielvaughn wrote:
| 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.
| modeless wrote:
| 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.
| debugnik wrote:
| 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.
| kbumsik wrote:
| > 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.
| westurner wrote:
| WebGPU: https://en.wikipedia.org/wiki/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]_
| rwmj wrote:
| Seems like an attack vector that I don't need. I turned it off in
| Firefox (about:config -> webgl.disabled == true)
| [deleted]
| [deleted]
| [deleted]
| baxuz wrote:
| Might as well disable JS. It's also an attack vector.
| rwmj wrote:
| I do that too, only enabling it on sites that need it. Finer-
| grained controls would be nice though. (I miss uMatrix ...)
| eikenberry wrote:
| 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.
|
| https://github.com/gorhill/uBlock/wiki/Blocking-mode
| aidanlister wrote:
| "How do you know if someone has disabled JavaScript? Don't
| worry" the joke goes ... "they'll tell you".
|
| 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.
| debugnik wrote:
| They were prompted to mention it by another user, though.
| Maybe the comments that don't add any value are "might as
| well disable JS."
|
| 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.
| baxuz wrote:
| Absolutely agreed. If we're going to be hyperbolic, the
| web itself is an attack vector. Better stay disconnected.
| chrismorgan wrote:
| I'm still happily using uMatrix.
| silon42 wrote:
| Yes. I'm not against ads, but if uMatrix stops working to
| block JS, I'll have to install uBlock for blocking ads
| (already do on mobile).
| Arnavion wrote:
| You have that finer-grained control with uBO. You just have
| to write the rules by hand instead of uM's table UI.
|
| https://news.ycombinator.com/item?id=26284124
| ravenstine wrote:
| Supposedly JShelter (formerly JavaScript Restrictor) wraps the
| WebGL APIs on a site-by-site basis.
|
| https://jshelter.org/webgl/
| jptech wrote:
| Not an attack vector per se, but largely used for
| fingerprinting.
| 1_player wrote:
| What's not used for fingerprinting nowadays?
| cookiengineer wrote:
| > What's not used for fingerprinting nowadays?
|
| HTML tags.
| mmastrac wrote:
| I'm not sure if this is sarcastic or not, but most likely
| not true.
| egberts1 wrote:
| Yes, WebGL remains a large surface area of an attack vector.
| WithinReason wrote:
| Disabling it makes your fingerprint more unique
| jptech wrote:
| Giving out a Null value has less entropy than a unique
| value. It may also be likely that it gets dropped when
| computing the overall fingerprint.
| [deleted]
| WithinReason wrote:
| if 20% of people explicitly disable it then it carries
| log_2(5) = 2.32 bits of entropy so it's not going to get
| dropped.
| tgflynn wrote:
| What would be a major example of something that can be done with
| WebGL 2.0 but not 1.0 ?
| The_rationalist wrote:
| moth-fuzz wrote:
| 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.
| brrrrrm wrote:
| I was curious about the same thing, here's a list I found:
| https://webgl2fundamentals.org/webgl/lessons/webgl2-whats-ne...
|
| I guess a big one outside of graphics is integer textures and
| bit manipulations. The rest seems like general built-in
| additions.
| marginalia_nu wrote:
| So how long until someone starts mining bitcoin on my GPU
| whenever I visit their site?
| cookiengineer wrote:
| Lots of scammy ad providers already mine monero in the
| background.
| easrng wrote:
| That's not true anymore. It isn't possible to mine with
| RandomX (The current Monero algorithm) in browsers and make
| much of any profit.
| [deleted]
| account42 wrote:
| They don't need to make much of any profit since they are
| not paying for the compute.
| zamadatix wrote:
| 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.
| seanw444 wrote:
| True. The "much of" part can be striked-out. "Any profit"
| is more than "no profit", hence the incentive still
| exists.
| easrng wrote:
| Nope, they still have to not heat up the user's device
| too much or whatever so they don't get suspicious. Ad
| (fraud?) would be vastly more profitable.
| skywal_l wrote:
| 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.
| eole666 wrote:
| 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.
| mrspeaker wrote:
| I can't believe it's actually happening - I was resigned to the
| fact it was dead.
|
| 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!
| Narishma wrote:
| That looks pretty simple. Is there anything you're doing that
| wouldn't be possible in WebGL 1?
| e12e wrote:
| 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).
| myers wrote:
| Looks great!
| egeozcan wrote:
| 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.
| danuker wrote:
| Wow! A simple 3D game in 425KB.
|
| For me, google.com is 1.47MB. It makes you wonder what they
| put inside.
| grishka wrote:
| Way too many abstractions.
| miohtama wrote:
| This is not the world we wished for, but this is the world
| we deserve.
| encryptluks2 wrote:
| Nah, we don't deserve it. We just don't have a choice at
| this point until someone is capable of creating an
| alternative to JavaScript.
| CamperBob2 wrote:
| _Nah, we don 't deserve it. We just don't have a choice
| at this point until someone is capable of creating an
| alternative to JavaScript._
|
| Didn't you mean "an alternative to Google?"
|
| Don't blame the tool for the (lack of) craftsmanship.
| jlokier wrote:
| 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.)
| Angostura wrote:
| > Latest Safari cannot be used by users who cannot run the
| latest MacOS on their hardware
|
| Yes it can - pretty sure my daughter's old Mac running Mojave
| got an update to the newest Safari a few days ago.
| extra88 wrote:
| 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.
| lern_too_spel wrote:
| The current version of Chrome can run on a version of
| Android that was released in 2014, meaning it can run on
| devices released in 2013.
| salamandersauce wrote:
| 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.
|
| EDIT: Chrome 98 also works on Android 6.
| Sheepsteak wrote:
| You can get the latest Safari for Big Sur and Catalina too.
|
| https://en.wikipedia.org/wiki/Safari_(web_browser)#Safari_15
| isodev wrote:
| 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...)
| nocman wrote:
| "all the way back"
|
| 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.
| chris37879 wrote:
| 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.
| blacksmith_tb wrote:
| 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).
| panzerboiler wrote:
| 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.
| simion314 wrote:
| Does it really work?
|
| 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)
| saurik wrote:
| That would certainly be a cute trick to look like they are
| helping but actually be taking a step backward.
| [deleted]
| ksec wrote:
| Does anyone know how far away is WebGPU from finalising? Are we
| even half way yet?
| solarmist wrote:
| It seems like trial implementations are in progress. But do you
| mean the spec or a released system?
|
| https://github.com/gpuweb/gpuweb/wiki/Implementation-Status
| AshleysBrain wrote:
| 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.
|
| [1] https://github.com/kakashidinho
|
| [2] https://lehoangquyenblog.wordpress.com/2020/09/30/google-
| ope...
| isodev wrote:
| 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."
| wffurr wrote:
| ANGLE has a bunch of great names for backends:
| MANGLE: ANGLE on Metal VANGLE: ANGLE on Vulkan
| SwANGLE: ANGLE on SwiftShader DANGLE?: ANGLE on
| Direct3D - dunno if anyone's ever called it that
| pjmlp wrote:
| And still SpectorJS as the only debugging tool available, far
| behind native GPGPU debugging tools.
| royjacobs wrote:
| Does this diminish the results of all browsers shipping decent
| WebGL 2.0 support, though?
| pjmlp wrote:
| Besides what fsloth replied, it is also 10 years too late,
| WebGL 2.0 is a subset of GL ES 3.0, released in 2010.
|
| So 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.
| mrdoob2 wrote:
| Safari did.
| fsloth wrote:
| It implies industry has little interest in actually
| supporting it. A GPU debugger is a critical tool in modern
| GPU development.
|
| Maybe they are holding on webgpu. People are carefully
| optimistic in it becoming the one API to be actually cross-
| platform.
| royjacobs wrote:
| 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.
| jcelerier wrote:
| > People are carefully optimistic in it becoming the one
| API to be actually cross-platform.
|
| idk I'm shipping code that uses the Qt RHI which works on
| D3D, GL, Metal, Vk ... cross-platform enough for me.
| emtel wrote:
| 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.
| pjmlp wrote:
| 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.
| teddyh wrote:
| Seems legit: https://caniuse.com/webgl2
| grenoire wrote:
| 87-88%, what's your point?
| teddyh wrote:
| I was not being sarcastic.
| stingraycharles wrote:
| Now I'm confused, is this comment "I was not being
| sarcastic" actually sarcastic, and as such the original
| post as well?
| teddyh wrote:
| No.
| dvh wrote:
| https://en.wikipedia.org/wiki/Poe%27s_law
___________________________________________________________________
(page generated 2022-02-17 23:01 UTC)