[HN Gopher] WebGPU now available for testing in Safari Technolog...
___________________________________________________________________
WebGPU now available for testing in Safari Technology Preview
Author : feross
Score : 139 points
Date : 2023-12-22 18:34 UTC (4 hours ago)
(HTM) web link (webkit.org)
(TXT) w3m dump (webkit.org)
| crakenzak wrote:
| Is it just me, or does it feel like Apple is putting more effort
| behind WebKit as of late?
|
| It's slowly becoming closer to chromium in cutting edge feature
| support.
| echelon wrote:
| Apple simultaneously doesn't want to become a thin client to
| the browser, yet they also see 3D/GPU/AI as the future and want
| to be at the forefront. They don't want to cede local compute
| to cloud and edge services.
|
| This is shaping up to be a fun battle ahead.
| mplewis9z wrote:
| I agree. They know their time is coming with being forced to
| allow other browser engines, and are actually putting in an
| effort now that there's competition on the horizon.
| brycewray wrote:
| If only Apple would free Safari from the OS release cycle, the
| way Microsoft did with Edge when the latter became Chromium-
| based.
| TheCoreh wrote:
| It's mostly free from the OS release cycle now: They have
| been shipping major web platform features in Safari versions
| that ship with their minor OS updates. (e.g. macOS 14.2, iOS
| 17.1) so every ~3 months, which is a nice cadence.
|
| The major OS release cadence only seems to affect major UI
| revamps which aren't that frequent anyway, so it's not that
| much of a limitation.
|
| You can now also update Safari independently of macOS, which
| is nice for IT environments that restrict major macOS updates
| until they have been approved.
|
| Hopefully in the future they will also allow that for iOS, so
| that older devices that can't update have some more longevity
| for web apps (and so that we as web developers don't need to
| support as many older versions)
| mcfedr wrote:
| It's not disconnected when it ships with os updates
| zshrc wrote:
| Apple has released os updates that have specifically
| targeted Safari issues. Usually point z releases as
| needed like big bugs and security fixes. Still not as
| ideal but it's better than before.
|
| Mind you the version string in Safari might not change as
| well. Gotta look at the build number.
| deergomoo wrote:
| I'd like to see it extended to all their bundled apps. I
| don't understand why a new version of e.g. Notes needs to be
| tied to an OS release.
| dylan604 wrote:
| if you were using updated apps on an outdated OS, then
| there's that much less incentive for you to upgrade the OS
| jacobp100 wrote:
| They've been hiring celebrity developer advocates too like Jen
| Simmons and recently Nichole Sullivan. But it has improved so
| much in the past few years too.
| MBCook wrote:
| This is sort of my sense. It feels to me more like it's just
| more people knowing about/noticing it.
|
| As a Safari user since release day I never felt like they
| slowed development or that they have accelerated it lately.
|
| But people are certainly more aware. Maybe it's more of an
| "it's all coming together" for a number of longer term things
| just hitting around the same time?
| freediver wrote:
| WebKit is already better than Blink for many cutting edge
| features, it is just that Apple and Google have different
| priorities in terms of what cutting-edge means.
| deergomoo wrote:
| They probably see the writing on the wall for their current
| restrictions on third-party browser engines, and are as
| interested in avoiding a Blink monoculture as the rest of us.
| jug wrote:
| I was thinking the same when I saw the release notes of the
| latest Safari stable version but wasn't sure if it was just me
| paying more attention than usual... :)
| vinni2 wrote:
| Finally time to run LLMs on browsers.
| fragmede wrote:
| Yes! Whisper's already running there, just need to get a bit
| further. https://whisper.ggerganov.com/
| magicmicah85 wrote:
| This is so incredibly impressive. The tiny model did such a
| fantastic job of transcribing an audio file for me.
| mkw5053 wrote:
| I'm curious why Apple is now putting effort behind the web when
| it competes with their app store distribution. Don't get me
| wrong, I'm excited they are. I can imagine a bright future for
| consumers where games with native-level graphics are distributed
| via the web.
| jacobp100 wrote:
| Safari has been improving at rapid pace for a while now. They
| were the first to get ES6 support (and the only to implement
| tail calls), they're usually the first with CSS features
| cutler wrote:
| So why do a lot of sites I visit still fail in Safari?
| spullara wrote:
| Because they rely on features or behaviors that are only in
| Chrome?
| acdha wrote:
| It's rare to see that but almost every time I have looked
| it's been because the developer did something which used a
| Chrome API instead of a web standard. I've found it best to
| develop in Firefox and Safari, because Chrome almost always
| works the first time you test it and you don't accidentally
| introduce a dependency on something which is still being
| standardized.
| chrismorgan wrote:
| Honestly, this _hasn't_ always been my experience:
| multiple times I've targeted Firefox for doing something
| _mildly_ out of the normal but absolutely within spec and
| supported across the board for years, and then tried it
| in Chromium and found debilitating bugs, to the point
| where once in a case of CSS blending I just had to give
| up on the entire concept, or else the page would just
| stop rendering after 8192px.
|
| I've never _actually_ developed against Chromium, and my
| position as a staunch Firefox user (and a Nightly user at
| that, for at least eleven of the last thirteen years) may
| be negatively affecting my judgement in this, but
| although what you say may be true from a _features_
| perspective, I don't find that at all difficult to
| manage, and from a _bugs_ perspective my impression is
| that Chromium has historically tended to be much buggier:
| that Firefox shipped better quality, later, while
| Chromium shipped lower quality, earlier. Though I do get
| the sense that this is less true than it used to be, and
| that Chromium is generally of higher quality for features
| of a certain age now than five years ago. And I
| reiterate, this is about the vibes I've got, as a Firefox
| user. I've tended to have to file more interesting or
| problematic bugs against Chromium than against Firefox.
| acdha wrote:
| I'm not definitely not saying any browser is perfect -
| I've filed many bugs against all of the major browsers -
| but I think Chrome took over from IE in the category of
| browsers which a certain type of developer uses as the
| only browser and decides that if it works for them it's
| ready to ship. I'm not sure I've ever had someone rant in
| the inverse case saying that if code works in, say,
| Safari but not Chrome it must mean that Chrome is a
| terrible browser and shouldn't be used. That default
| mentality is toxic for the web but not uncommon.
| mdasen wrote:
| I haven't found this to be a problem, but if you do I might
| suggest looking at the options under the view menu.
|
| https://i.imgur.com/lMHkiH8.jpg
|
| "Reload Without Content Blockers" and "Reload Reducing
| Other Privacy Protections" might be what you need. It might
| be Safari's anti-tracking/cookie features that might be at
| fault or it might be that you have a content blocker that's
| causing an issue. If you're using iCloud Private Relay,
| it's possible that sites are filtering those IP addresses
| or there's a DNS issue and you can use "Reload and Show IP
| Address" to check that. For example, iCloud Private Relay
| often uses Cloudflare's DNS. archive.is doesn't work with
| Cloudflare's DNS (because Cloudflare won't leak your
| location to their DNS servers and so archive.is returns bad
| results to them).
| naet wrote:
| I've had various different issues with Safari as a
| developer for the last few years (also frequently paired
| with SVGs for some reason). In the absence of IE, Safari
| has the perfect combination of decent market share and
| bugs that for my company we get a lot more Safari
| specific reported issues than any other browser.
|
| It's usually smaller things like SVGs not working with
| CSS animations, or SVG filters causing weird edge case
| issues, but I'd really expect any major browser to fully
| support something like SVG and it's a little
| disappointing to find that the browser is the issue.
| olliej wrote:
| This is like saying "is X is better than IE, why do the
| sites that work in IE but not X".
| Angostura wrote:
| I only know of 1 where it is a current problem. What do you
| have?
| alwillis wrote:
| That's a web developer problem, not a Safari problem.
| nolist_policy wrote:
| Because to test with Safari, you need to buy a Apple
| device.
| boucher wrote:
| Anti-trust concerns
| marban wrote:
| Even the App Store has a shelf life.
| holoduke wrote:
| I expect webstores to be less relevant in 5 years from now. PWA
| are getting more on pair with their native sisters. Banking
| apps, social media etc . There is no real reason to have a
| native app. Only graphic demanding apps will have a slightly
| longer life. But the end is near for Kotlin and Swift apps. I
| cannot be more happy.
| vladgur wrote:
| What's a good site that lists current differences between
| native apps and PWAs?
|
| Like can PWAs run in background or respond to location
| changes, etc
| scarface_74 wrote:
| So if that's true, why are app developers still releasing
| Android apps instead of just letting them use the web
| version?
|
| And I haven't heard anyone say "you know I have a really
| great experience with web apps. I wish all of my apps were
| web apps on mobile and Electron on my computer"
| jampekka wrote:
| I'm wondering about the same. Vast majority of "apps" would
| work just as well, or better, as a website. In fact a lot
| of them do, e.g. this very site.
|
| I think a part of it is an "app craze", i.e. organizations
| want "apps" just because "an app" is something fancier and
| totally different than "just a website". I have done an
| "app" like this (implemented as an optionally installable
| website).
|
| Also many people, including many developers, also vastly
| underestimate what can be done with contemporary browsers,
| so they assume that "a native app" is needed if you e.g.
| want to take a picture or read a file.
| jamil7 wrote:
| Because PWAs on mobile remain kind of underwhelming still.
| Native APIs are missing, navigation stacks are not there
| and performance is still quite bad even on higher end
| phones, although the last one is probably implementation
| specific. There are also only two platforms so the
| insensitive for businesses aren't as strong.
| diegof79 wrote:
| I'm not sure if I'll be happy about a future where everything
| is a PWA.
|
| My main concern is monetization.
|
| With a PWA the traditional monetization method of selling
| apps doesn't work. So, your options will be a subscription or
| ads.
|
| But, a subscription is too much hustle for small utilities
| and casual games. And I love apps like Procreate that are
| paid, without subscription and ad-free.
| uxp8u61q wrote:
| > With a PWA the traditional monetization method of selling
| apps doesn't work. So, your options will be a subscription
| or ads.
|
| How so? Offer to install the pwa and unlock functionality
| only after the user has paid. How is that different from a
| paid "app"?
| Uvix wrote:
| On the app stores, you can redownload purchases at any
| time. With a PWA you're dependent on the vendor still
| supporting the app.
| deergomoo wrote:
| > So, your options will be a subscription or ads.
|
| We're basically there already unfortunately, even for
| store-distributed software. Apps like Procreate and
| Pixelmator are a rarity these days.
|
| It definitely doesn't help that the App Store makes
| charging for new major versions awkward, and that upgrade
| discounts are basically impossible, but I suspect the main
| reason is that most developers just make more money from
| subs than purchases.
|
| As a consumer though, it sucks. Subscriptions are fine if
| your product has an ongoing cost to you as the developer,
| for example server or API fees. And I really don't mind
| JetBrains-style subs, where you can cancel any time and you
| retain access to the last version you paid for, for as long
| as it still works on your machine. But, while I appreciate
| the need for ongoing revenue to continue paying salaries, I
| am not interested in renting software in perpetuity--that's
| not a fair deal. Especially when it robs me of the ability
| to stick with an older version if I prefer it.
| clumsysmurf wrote:
| The reason why banking apps are native, not web, is to
| collect rich fingerprinting for fraud detection and
| prevention... not for any specific "rich UI" experience, etc.
| troupo wrote:
| > PWA are getting more on pair with their native sisters.
|
| Not really, no
|
| > There is no real reason to have a native app.
|
| Except, you know, for all the reasons where anything web-
| based sucks: resources needed to run, fast reaction times,
| performant animations, rich complex controls etc.
|
| The web, unfortunately, made everyone accept the most limited
| and under-developed version of what things could be.
| dfgfek wrote:
| Web-based apps have been getting more on pair with native
| apps since 2008. They still aren't there and they are likely
| to never get there.
| bonestamp2 wrote:
| I wouldn't say never. I mean, you might be right, but
| between GPU support and WebAssembly, there is a lot of
| potential for web-based apps to become more popular than
| native apps in the future. It's all going to come down to
| the developer and user experiences of each.
| IshKebab wrote:
| Possibly because it's looking likely that they'll be forced to
| allow other browsers on iOS at some point and they don't want
| everyone to switch to Chrome?
| afavour wrote:
| Apple tends to put effort behind web APIs long after others do.
| WebGL, progressive web apps, etc etc... they put the effort in
| when it's starting to become a competitive disadvantage not to.
|
| WebGPU feels like an outlier in that respect but then it is
| intended as a "better" WebGL so it makes sense that if you
| already have WebGL you might as well have WebGPU. It's a lot
| closer to Apple's Metal API than WebGL is so they have an
| interest in people switching.
| modeless wrote:
| The EU's DMA law is going to force them to finally start
| competing with other browser engines on iOS, at least in
| Europe. When that became clear they started investing more in
| WebKit. It's been a few years now.
| hmottestad wrote:
| I switched from Chrome to Safari on my Mac about 7 years ago.
| At the time Apple was promoting performance and power
| efficiency. I've been very happy. Sometimes I do run into css
| stuff that is missing, and PWA is still not great. Latest PWA
| screw up is that the app won't switch to dark mode except if
| you force quit the app, and then it gets stuck on dark mode.
| This worked perfectly prior to iOS 17.
|
| My point is that Apple is competing with other browser
| implementations on MacOS, yet I've very rarely used anything
| other than Safari. Most exceptions have actually been because
| I need a plugin to debug the JS framework I'm using.
| naet wrote:
| They're competing a lot less than they could be by nature
| of being the default browser, and also by not allowing non-
| webkit based browsers on the iOS apple store. I think
| without those very few people would be opting in to Safari.
|
| I read that both Google and Mozilla are developing non
| webkit iOS browsers in anticipation of some regulatory
| changes, and also that Apple has been staffing up the
| webkit/Safari team in response.
| idonotknowwhy wrote:
| Lack of real Firefox is the actual blocker for me using
| an iPhone. But at the same time, I'm glad ios only allow
| safari and I hope the EU don't change this. I think the
| consequences would be bad if chrome works on every
| platform and suddenly there's no cross browser support
| for a lot of apps.
| modeless wrote:
| You are not a representative sample. According to [1]
| Safari has 28% market share on MacOS. [Edit: This site was
| wrong, the real number is 37%, see below for a link]
|
| If WebKit's market share on iOS were to drop this low, web
| developers would likely test for WebKit a lot less, and
| tolerate WebKit's missing features a lot less, and Apple
| would soon face much worse web compatibility problems on
| both platforms. To prevent that they saw that they needed
| to seriously step up their investment in WebKit, and from
| what I've observed it seems like they did. Though perhaps
| not yet to the level they really need. Old habits die hard.
|
| Of course they could just do what Microsoft did and give
| up. I'm glad they haven't.
|
| [1] [Edit: this site was wrong, see below for better
| numbers]
| Angostura wrote:
| Most recent data is from 2020 according to the text at
| the top of the page
| hmottestad wrote:
| I tried to find other sources, not easy I must admit.
|
| https://radar.cloudflare.com/reports/browser-market-
| share-20...
|
| Cloudflare puts Safari at a bit under 40% for MacOS, so
| it looks like I'm very much n=1 and not particularly
| representative. Marketshare for Safari on MacOS is close
| to 85%, so I can definitely see that changing if users
| could install real alternate browsers.
| modeless wrote:
| Thanks for finding a better source! Sorry about the
| misleading number before.
| hmottestad wrote:
| Not that much difference between the two really. And
| compared to iOS it's a stark contrast to how Safari is
| doing on Macs.
| mdasen wrote:
| One could say the same for Google's browser investments as
| well. At this point, if Chrome and Safari don't implement
| something, it basically doesn't exist as a web technology. The
| only other engine is Firefox sitting at 3% of usage.
|
| In Apple's case, I think there's some utility behind their
| drive for WebGPU: it's basically Apple's Metal graphics API. If
| WebGPU takes off, it'll mean a lot of developers getting
| familiar with something very similar to Apple's Metal API.
| Apple seems to be pursuing a long-term strategy of bringing
| more games to their platform. From the Game Porting Toolkit to
| ray tracing in their processors to Apple Vision to simply
| giving gaming a lot more attention in their keynotes.
|
| And Apple might be well positioned to capitalize on gaming. A
| $130 Apple TV has a lot more CPU and graphics power than a
| Nintendo Switch. The same applies to the iPhones people are
| carrying around. It might not compete with giant consoles from
| Microsoft and Sony, but Apple has been showing that it can
| offer impressive gaming performance.
|
| Fast forward to 2026: does a next-gen Apple TV have hardware
| ray tracing? Apple put a 2021 A15 processor in the 2022 Apple
| TV. It seems reasonable that they could put something better
| than a 2023 A17 Pro in a 2026 Apple TV (a 3 year old processor
| at that point). Sure, Microsoft and Sony will have next-gen
| consoles, but at what point are graphics facing diminishing
| returns? Nintendo has the most popular console even though it's
| older and was low-powered to begin with. For PC games, one must
| assume that some people are running graphics cards that are
| older.
|
| I'm not saying this will happen. Companies can be fickle.
| However, Apple has show a reasonably consistent (if slow) move
| toward games over the past year or two. They're making the
| investments now and WebGPU's Metal-like API could be part of
| that strategy.
|
| Heck, maybe WebGPU is even a strategy to avoid lawsuits from
| companies like Epic and anti-trust action from regulators. If
| you don't like the App Store rules, just use WebGPU. If games
| with native-level graphics can be distributed via the web, then
| there isn't nearly as much for regulators to go after the App
| Store.
| scarface_74 wrote:
| This take doesn't survive scrutiny. The real money from the App
| Store comes from play to win games. The reason those make so
| much money is because of the direct link to in app purchases
| and "whales" spending money on meaningless coins and loot
| boxes.
|
| This came out in the Epic Trial. Those people are much less
| likely to put a credit card on any random site.
|
| Candy Crush games could already be done on the web on mobile -
| it wouldn't be nearly as monetizable
| megaman821 wrote:
| Candy Crush running in Safari can use Apple Pay almost as
| easily.
| madeofpalk wrote:
| I would imagine Apple Pay is used significantly less than
| iTunes/App Store billing.
|
| Apple Pay is only in certain counties, with supported
| banks/cards. iTunes/App Store supports a plethora of
| payment options across the world, as well as Apple Pay.
| realusername wrote:
| Indeed, you could totally make the argument based on the
| store revenues that both the play store and the appstore are
| just in reality some type of casino/gambling industry
| middleman.
|
| Both companies are working very hard to remove this image
| though for obvious political reasons.
| megaman821 wrote:
| It could also be strategic. A more capable web browser along
| with better PWA support, could be an offering to the EU to
| settle app store monopoly issues. Apple could say they have
| made it so easy to install quality apps from the web there is
| no need to mandate alternative stores.
| bonestamp2 wrote:
| On this same point, if they don't keep up with PWA support,
| they risk getting left behind by application developers. So,
| they have multiple incentives to invest in Safari.
| ComputerGuru wrote:
| > they risk getting left behind by application developers
|
| There is literally, for now, zero risk of that. companies
| will have devs meet the customers where they are at. Of the
| largest mobile market share platform in the USA doesn't
| support PWA or only supports it without features the
| company requires, said company will build an iOS app. As
| has been the case.
| sccxy wrote:
| iOS PWA support is getting worse and worse with every
| release...
|
| iOS 16.4 added new wake lock api but it does not work in PWA.
| Still not fixed in iOS 17.2
|
| iOS 17 removed dark/light mode switching in PWA. Still broken
| in iOS 17.2
| madeofpalk wrote:
| Safari's always been pretty secretly good - they just got a bad
| rep for not supporting PWA-related technologies for a while.
| Because Apple uses Webkit to render a bunch of their "native"
| UIs, they're often first to adopt native-like interactions or
| css features (or proposed them themselves), like backdrop-
| filter or CSS Scroll Snap. Because the web can have a pretty
| big impact on battery life on phones and laptops, they've also
| always had a pretty fast and energy efficient js engine.
|
| I'm really doubtful Apple sees Safari as competition for their
| app store distribution. I don't think that matches reality of
| how most consumers use mobile devices and spend money.
| MBCook wrote:
| I agree.
|
| I don't think they see Safari as competing with the App
| Store. Even with the recent PWA additions it doesn't seem to
| matter.
|
| At this point I'd say Safari is 100% a hedge against being
| fully dependent on Google/Chrome. It started to not be
| dependent on MS/IE and improve what MS didn't care a ton
| about.
|
| Apple HATES being fully dependent on others for very
| important stuff. They've been burned too many times.
|
| Safari is great. I love it. But there's no way it is ever
| going away even if they are forced to preload 18 different
| app stores and 4 browsers on every phone by the different
| governments of the world.
|
| It's Apple keeping control of Apple's destiny.
| rglover wrote:
| The web is getting more powerful and eventually will negate the
| need for native apps as the performance will be comparable or
| greater. I'd view moves like this to be preemptive efforts to
| remain competitive in the future.
| JayStavis wrote:
| On the webGL/GPU side, my cynical speculation is that the Apple
| has slowly been amassing a nest of graphics talent for the last
| 5 years (Metal, Vision Pro, ARKit, list goes on), and at this
| point they can't resist the pressure from employees to not
| support some of this stuff which should be table stakes and is
| obviously good for the user experience.
|
| On the PWA side, best guess is anti-competition scrutiny.
| 3836293648 wrote:
| So is this a third implementation or is it using Dawn or wgpu?
| troupo wrote:
| You could call it the original implementation. Because Safari
| (in collaboration with Firefox) are the ones who presented the
| WebGPU proposal
| flohofwoe wrote:
| WebGPU doesn't have much in common with Apple's original
| proposal (which was more or less a Javascript API around
| Metal). I suspect the new implementation is a complete
| rewrite from the original proposal, since earlier versions of
| Safari contained an implementation of the Apple proposal,
| which was then removed for a very long time while work
| happened on WebGPU.
| Lichtso wrote:
| While that is true, it also true that Apple had a major
| influence on the current design and is e.g. the reason why
| we got WGSL [0] as a source language instead of a bytecode
| (a GPU WASM equivalent if you will).
|
| [0]: https://www.w3.org/TR/WGSL/
| slimsag wrote:
| People keep spreading this incredibly misleading
| statement - god knows I do not like Apple's closed-source
| behavior, but at this point people are basically just
| spreading lies about the situation
|
| By all accounts, Apple's /only/ stance was that if WebGPU
| used SPIR-V it would be a non-starter for them, due to
| ongoing legal issues between Apple and Khronos.
|
| Apple actually proposed WebHLSL in collaboration with
| Microsoft, to have HLSL be the standard.
|
| Mozilla employee's stance[0] was that SPIRV was too low
| level, did not fit with the goals of WebGPU portability
| and security, and expressed concern that Khronos may add
| functionality to SPIRV they cannot support in WebGPU like
| raytracing instructions .. 'So we'd always be on the
| verge of forking SPIR-V in some way.'
|
| It was also noted by many people that even if a bytecode
| format was used, it would still have to be translated to
| the target (HLSL/DXIL, MSL, etc.) in almost the same way
| a text format would.
|
| Nobody proposed a 'GPU WASM equivalent' or an alternative
| bytecode format, only SPIRV was ever considered AFAIK.
|
| The hard truth is that shader compilation is a fucking
| nightmare, people do not realize how bad it is across the
| different native APIs. SPIR-V is good, but it doesn't
| solve that - and presents other challenges if you are a
| web browser API. Vulkan and SPIRV are not the golden
| goose many make them out to be.
|
| [0] https://github.com/gpuweb/gpuweb/issues/847#issuecomm
| ent-642...
| Lichtso wrote:
| I might have expressed myself in an ambiguous and
| extravagated way, just to be clear, I was not complaining
| about WGSL. I actually do like it a little better than
| GLSL and HLSL, though it still leads to more standards /
| fragmentation.
|
| And exactly, Apple did not want SPIR-V (a bytecode) and
| proposed WebHLSL (a textual source language) instead. So,
| I think my statement that Apple preferred a textual
| format over a bytecode is correct. They could have
| proposed another bytecode format, but as you noted,
| nobody did.
|
| It does not really matter anyway, because the GPU
| hardware and software paradigms are still undergoing
| rapid change. And there are a whole lot of under-
| specified things like memory models, scheduling order,
| control flow uniformity etc. which I expect will take
| another iteration of standards to be established.
| flohofwoe wrote:
| It's a third implementation in WebKit:
|
| https://github.com/WebKit/WebKit/tree/main/Source/WebGPU
| jamesfmilne wrote:
| I'd love a first-class WebKit-based browser on Linux. I have
| looked recently, am I missing one? Gnome Web is a like a Fischer-
| Price browser.
| ho_schi wrote:
| Epiphany is nice. Especially because it features a native
| toolkit with Gtk4. What few developers do is incredible :)
|
| Main issues: * Since introduction of
| sandboxing the memory-usage is far too high. It was pretty low
| before. * WebRTC. They had it nearly implemented
| years ago. Then removed it because they were unhappy with it.
| But their new approach isn't available until now. *
| Many more developers needed. This means me? *
| Epiphany releases are linked to GNOME releases. Only
| applications which are integrated parts of GNOME should do
| that. The rigid six months release cycle is problematic.
|
| Regarding memory usage. Sandboxing depends on multi-process.
| The multi-process shouldn't be an issue. The sandboxing was
| added in late 2019 and - if I remember correctly - Epiphany
| started to eat memory. Like probably most people I keep my tabs
| when closing/opening the Web-browser. The developers are nice
| and explained, that for all previous existing tabs a separate
| sandbox process and a render-process is already started with a
| blank page. And due to need separation no process is allowed to
| share memory with others. What is needed is only showing a
| label on the tab until the tab is actually used.
|
| And. Midori? There was previously also Midori using WebKitGtk.
| I liked it and it was pretty nice. But something awkward
| happened and an unrelated people took over the name and started
| to ship Electron (i.e. Google Chrome) as "Midori". It looks
| untrustworthy to me, I recommend to not install it.
|
| If you use Midori on Archlinux you should be save - they ship
| and old and original version of Midori. But it is old.
|
| Apple, WebKit and WebKitGtk work together for many years. Good
| work.
| firtoz wrote:
| WebXR will be nice too especially for iPhones...
| bhouston wrote:
| I would love that. Finally across platform AR experience.
|
| Apple is using WebXR for the Vision Pro, but it isn't clear if
| it will ever be available on iPhones.
| TheLoafOfBread wrote:
| Now make Web BLE available as well, and I am happy.
| bhouston wrote:
| You can track over time the availability of WebGP on browsers via
| https://web3dsurvey.com/webgpu. It is already up to 57% of
| browsers surveyed.
| rwbt wrote:
| It'll be very nice if Apple also releases a standalone
| WebGPU.framework (or just expose the APIs in WebKit.framework) so
| we can finally have a true cross-platform OpenGL successor for
| native development.
| aseipp wrote:
| Can't you have that today by using Dawn (used by Chrome) or
| wgpu (used by Firefox) as a dependency? That said, a third
| implementation would be nice, too!
| rwbt wrote:
| A third implementation and also having a WebGPU.framework
| built-in and shipped with the OS (like all other first party
| frameworks) would simplify the build and debug process.
| tormeh wrote:
| Why? Isn't it easier to bundle your dependencies rather
| than deal with whatever may or may not be installed on the
| client system?
| JeffSnazz wrote:
| The cross-platform "OpenGL successor" seems to be gfx-rs. It's
| not clear why one would expect a specific vendor to champion
| this.
| lpghatguy wrote:
| gfx-rs hasn't been maintained for several years. The
| successors are definitely wgpu or Dawn, which are championed
| by browser vendors.
| adastra22 wrote:
| wgpu is gfx-rs, no? It's just a name change.
| sccxy wrote:
| Give it at least few major iOS updates before it is usable.
|
| It is almost a rule with webkit new features.
|
| Those new APIs almost work, but you need to use user-agent
| detection to make sure it really works and it does not fail
| randomly/silently when it is in home screen or some other iOS
| browser.
| breckenedge wrote:
| Safari Technology Preview is not available on iOS.
| neoberg wrote:
| what's that mouse cursor in the demo video?
| orenlindsey wrote:
| I tried it and it didn't work. Downloaded Safari Technology
| Preview on my 2023 MBP and it returned various errors in all the
| WebGPU demos I tried.
| dev_tty01 wrote:
| Did you enable the required developer flags?
|
| From the preview page:
|
| To enable WebGPU, turn on the "WebGPU", "GPU Process: DOM
| Rendering" and "GPU Process: Canvas Rendering" feature flags in
| the Feature Flags tab in Safari Preferences. If you don't see
| the Feature Flags tab, you need to first check "Show features
| for web developers" in the Advanced tab.
| singularity2001 wrote:
| The last time I tried it they had a different API to chrome.
| you can check the Apple examples the methods and values have
| slightly different names
| sroussey wrote:
| After enabling the feature flag, the samples here worked fine:
|
| https://webgpu.github.io/webgpu-samples/
| fidotron wrote:
| I am torn about WebGPU - on the one hand it is a necessary
| improvement, but it does radically increase the attack surface
| area in ways that just a few years ago would have been complained
| about by the browser security teams. (The spectre countermeasures
| around high resolution timing can still bite you).
|
| This makes me suspicious that something has changed to push the
| balance here, and it must be something to do with trying to
| offload the execution of LLMs and related neural networks on to
| clients to reduce the cost of doing it server side.
| michaelt wrote:
| Current LLMs have vram and power requirements that mean it's
| unlikely we'll see a decent LLM running on phones without a
| step change in technology.
| atarian wrote:
| Very interesting how similar the code for setting up the pipeline
| is similar to Metal.
| adastra22 wrote:
| That's not a coincidence.
| sroussey wrote:
| I am looking forward to this coming to Bun!
| timenova wrote:
| I remember Safari had a flag for WebGPU a year or two ago. I even
| tried some samples and it seemed to work. Does anyone know why
| they removed it in the middle?
|
| IIRC Safari had the flag too that time, not just the Technical
| Preview.
___________________________________________________________________
(page generated 2023-12-22 23:00 UTC)