5 ms·

> On macOS, for example, Zed makes direct use of Metal. We have our own shaders, our own renderer, and we put a lot of effort into understanding macOS APIs to g

> On macOS, for example, Zed makes direct use of Metal. We have our own shaders, our own renderer, and we put a lot of effort into understanding macOS APIs to get to 120FPS. So they are taking the exact opposite approach of Electron (VS Code). In my mind, if you're someone who types in HN comments in a rage because your text editor (VS Code) eats up 200+ MB ram, you don't get to cry about Zed not being supported on Linux from day one, because you can't have your cake and eat it too - if you want it on your platform, you gotta wait for the shaders to be written.

jonhohle 2y ago
Or… use one of the existing cross platform toolkits that have existed for decades. Text Editors, traditionally, did not require shaders to run or be performant, and not require entire systems worth of RAM.
- MR4D 2y ago
  Out of curiosity, how many of them run at 120 FPS? (honest question - I've never looked into it myself)
  - forgotpwd16 2y ago
    This is the first time I see FPS mentioned for a text editor. Is this something that matters or just an pointless metric utilized as selling point?
    - SomeRndName11 2y ago
      Well it may have effect on ergonomics. Some people claim they cannot use 60Hz monitor after trying 144hz.
      - NekkoDroid 2y ago
        Well, that is usually refering to some form of "simulated fluid motion", not new characters appearing and disappearing. The only case where that kinda fluid motion would matter is when you have text scrolling by at semi-fast speeds.
        ffsm8 2y ago
        I count myself among the people that would consider >60hz necessary. For me, it's animations, especially if I'm dragging a window or just the mouse. On 60hz it's nauseating if I'm paying too much attention to the window I'm moving. It's goes completely away around 90-100 Hz (at least for me)
        LoganDark 2y ago
        I've had the privilege of using a merely 90Hz display and the difference is still incredible. It gives me input feedback much faster so my brain does not have to do as much buffering/prediction, everything feels a lot more direct. One would think a measly 5 milliseconds wouldn't amount to much, but for input feedback it absolutely does. I do not suffer from nausea or motion sickness of any kind arising from computers or visuals in general, but I can still easily tell the difference between a 60Hz and 90Hz display. A few months ago I had the privilege of checking out the 120Hz displays on the new MacBooks and they're amazing.
        NekkoDroid 2y ago
        I'd still say that draggin a window would count as a "simulated fluid motion". Maybe not something you'd immediatly think of, but its still trying to convey the sense of motion. Just text appearing and dissappearing isn't something I personally could categorize ass the same type of animation. And I also count myself as someone who considers 120 at least necessary (on the primary monitor)
    - freqmod 2y ago
      Fps in itself is not important, but it is a substitute for input latency, and if your keystrokes start lagging it feels sluggish. At least historically electron based editors (like atom) has been feeling significantly more sluggish than sublime text or vim with a decent terminal emulator.
      - forgotpwd16 2y ago
        For terminal emulators comparisons at least the metrics used are latency and throughput. Now those plus times to do operations (load file, search & replace, etc) wouldn't surprise me to be the comparison metrics for text editors. FPS though feels weird.
    - sunshowers 2y ago
      As far as I can tell, graphics pipelines often use frame buffering. The quicker the next frame can be drawn, the faster it feels.
      - adastra22 2y ago
        GUI apps like text editors don’t redraw frames every update cycle.
  - adastra22 2y ago
    The question doesn’t make sense. They don’t rerender the buffer every frame. I assume zed isn’t doing that either as it would be horribly inefficient. I presume what is meant is that it can handle a redraw fast enough to be in the next frame. In which case the answer is: all of them. Drawing text is not the bottleneck for a GUI program, unless you have a god awful browser stack as your rendering engine.
    - LoganDark 2y ago
      > I assume zed isn’t doing that either as it would be horribly inefficient. What are you supposed to do instead? Zed uses the GPU. It's not making calls to retained-mode widgets to individually reposition them, nor is it blitting into a buffer using the CPU. It's using the GPU which eats pixels for breakfast. You've been able to rerender the entire screen each frame for over a decade - just look at Windows 7 Aero, which ran on the laptops of 2009 for the exact same reason: it used the GPU!
      - zozbot234 2y ago
        Rerendering each frame is wasteful because it keeps hardware from reaching deeper power-saving states. This includes the CPU, GPU and even the display, due to technologies such as FreeSync. On modern hardware, even removing the blinking cursor has been found to save quite a bit of power, by eliminating needless screen redraws.
        justinclift 2y ago
        > ... even removing the blinking cursor has been found to save quite a bit of power, by eliminating needless screen redraws. Hadn't heard of that before, but it makes sense now you mention it. :)
        LoganDark 2y ago
        Zed only rerenders the window each time it changes (and also for about a second since the last interaction for reasons[0]) but every time it rerenders the window it does rerender the entire window and not just the area that changed. That's what I thought GGP was calling horribly inefficient. [0]: https://zed.dev/blog/120fps https://zed.dev/blog/120fps
  - jethro_tell 2y ago
    Honest question. What could you possibly do with a text editor at 120 fps that you can't do at 15 or 30? I can't think or type that fast and I can't read scroll back that fast either so I can't wrap my head around needing something like that.
    - ajross 2y ago
      > Honest question. What could you possibly do with a text editor at 120 fps that you can't do at 15 or 30? More-honest-than-it-should-be answer: sell a product to Apple-ecosystem developers trying desperately to find something to justify the $3k they want to spend on a new MBP. (Typing this very comment in emacs running out of the Linux VM on a mid-range chromebook attached to a 30 Hz 4k television, btw. Come at me, as it were.)
      - jethro_tell 2y ago
        Heh, rocking a self built tmux/vim setup her myself, but even still I don't think I'm so cynical to think the only reason is for the marketing speak. I assume they have a reason, I just can't guess whatnot is.
        ajross 2y ago
        I'm... absolutely that cynical. 120 Hz displays and the horsepower to drive them are the golden boutique speaker wire of the Gen Z tech set.
        Dylan16807 2y ago
        Oh come on. Fancy wires do nothing. 120Hz makes motion much smoother. It also reduces latency. Those make a big difference in many video games, or even just moving my mouse around and having it not skip two inches at a time. Your cynicism over 120Hz should match your cynicism over 4k.
        jethro_tell 2y ago
  - whazor 2y ago
    Chrome supports 120Hz+ https://www.testufo.com/browser.html https://www.testufo.com/browser.html It also seems like you can configure VSCode to go faster: https://stackoverflow.com/questions/52230196/vs-code-is-visibly-not-running-over-60fps-on-144hz-monitor https://stackoverflow.com/questions/52230196/vs-code-is-visi... But honestly, 'responsiveness' should come from not blocking the main/UI threads, and rendering in the right order of importance.
- phendrenad2 2y ago
  If you want a shaderless text editor, just use NotePad. But the world has moved on and people like their text to look nice.
- jamil7 2y ago
  Cross platform toolkits, more than other software components incur massive tradeoffs. They’ve written one themselves, tailored to their needs and open sourced it along the way. I guess I don’t see the problem here. If one that’s existed for decades fits your needs better then use that.
  - jauntywundrkind 2y ago
    Wgpu seems very very well loved & supported, is one of the most successful comings together of the graphics world in ages. I'd love to hear some actual critique of it, hear what people think are shortcomings, because it feels to an outsider like this is the fantasy land, that we're living in the better place now. https://github.com/gfx-rs/wgpu https://github.com/gfx-rs/wgpu
    - auggierose 2y ago
      Well, it's Rust. I am using TypeScript. I guess I am sticking with Electron. Maybe WebGPU can help me out.
    - littlestymaar 2y ago
      What I find interesting is that kvark, the open source contributor that made Linux port possible was the main developer on wgpu at Mozilla, yet he decided to build an alternative [1] to wgpu that he used for zed. I wonder what's the rational for that. [1]: https://github.com/kvark/blade https://github.com/kvark/blade
      - jauntywundrkind 2y ago
        Dzmitry gave a talk at a rust gamedev meetup on Blade. This ain't my turf so apologies for inaccuracies here. It appears to be a fairly novel attempt to write a graphics library with a semi conventional looking pipeline, that under the hood ends up eskewing a lot of the Vulkan concepts. Instead of per object contexts, it uses global contexts to do most work. Instead of taking resources and binding them into descriptor sets to use across pipelines (tracking state), Blade kind of recreates resources on the fly, lets them get used, and disposed of them. Kind of interesting philosophy of a complex binding model in Vulkan/WebGPU vs a more direct diy render model? https://www.youtube.com/live/63dnzjw4azI?si=KzLPm-gBX0gDKq7H#t=12m45s https://www.youtube.com/live/63dnzjw4azI?si=KzLPm-gBX0gDKq7H... Zed tool this work as an outside contribution. Maybe that someone did the work was good enough. I'm not sure what would make Blade a better match or not, vs wgpu-hal.
- Iwan-Zotow 2y ago
  > Text Editors, traditionally, .. and not require entire systems worth of RAM. Emacs is looking at you
nemomarx 2y ago
I suppose ideally you'd want it to be written on Linux first, if you're that kinda person - but the market is probably on Mac?
- m463 2y ago
  I remember reading a long time ago (think pre-intel macs) that game developers never developed for macs. However if they did, the games would sell because the mac people wanted games and there were so few available they would buy anything. problems of a closed ecosystem.
  - thfuran 2y ago
    Circa 2000, a lot of big name games actually were released for Mac. Heroes III, StarCraft, and Diablo II, for example, all got Mac releases.
  - wmf 2y ago
    Because Macs are expensive (in absolute terms) Mac users are a self-selected group who are willing to spend money. Linux users have high standards and are not willing to spend money. For a text editor in particular Linux is going to be the toughest market because it's already pretty saturated.
  - pjmlp 2y ago
    How do you think iDevices games are developed?
- from-nibly 2y ago
  Doing it on Linux would make people ask "why isnt it on my distro" a LOT sooner. Thus adding complexity while you are trying to prove the concept.
duxup 2y ago
Someone has to pay for it, time, money, wait for it whatever. I love working with technical people who ask why and think about more optimal paths. On the other hand I'll listen to the same folks complain about some random app being stinky (I don't disagree) and wonder "Yeah but you going to pay more for that burrito so that company can hire folks to write it natively on every platform?" No you're not ... I know our customers at times aren't willing to pay / wait for the optimal path, and their customers aren't, so I get it.
NoraCodes 2y ago
> In my mind, if you're someone who types in HN comments in a rage because your text editor (VS Code) eats up 200+ MB ram, you don't get to cry about Zed not being supported on Linux from day one, because you can't have your cake and eat it too - if you want it on your platform, you gotta wait for the shaders to be written. This is certainly one takeaway. On the other hand, this very blog post points out that a community member, Dzmitry Malyshau, did the work to get the program working on the OS he uses. Malyshau does not work for Zed, which is a for-profit company; as far as I can see, he gets nothing out of working on Zed, except that he and other Linux users get to use it. Perhaps, rather than characterizing Linux users as whiny, we could take away the idea that many Linux users are willing to put in quite a lot of work to make things better for each other.
- weinzierl 2y ago
  "Perhaps, rather than characterizing Linux users as whiny, we could take away the idea that many Linux users are willing to put in quite a lot of work to make things better for each other." ... and that even if it means signing away their rights in a CLA to a for profit company. This is on another level than contributing to the Linux kernel that is GPL2 plus practically not relicensable because of the multitude of copyright holders.
- justinclift 2y ago
  > Perhaps, rather than characterizing Linux users as whiny, we could take away the idea that many Linux users are willing to put in quite a lot of work to make things better for each other. That's more an "Open Source" thing rather than Linux specific. A personal case in point was when I got Mellanox adapter support officially added to FreeNAS (now TrueNAS) because that's the adapter brand I had and needed it to work. Not a super huge effort as the FreeBSD driver worked (so just needed porting), but the integration process and follow up testing/advocacy/etc work wasn't exactly trivial either.
hvis 2y ago
MoltenVK is also a thing. Whatever small translation overhead it incurs is probably not that important for a text editor. And then you get a cross-platform API: not just Linux, but Windows as well. Maybe also other more niche OSes as well.
- skohan 2y ago
  Molten VK is amazing. When I started working with it, I was expecting a lot of caveats and compromises, but it's shockingly similar to just using Vulkan that you can easily forget that there's a compatibility tool in play. Probably you can squeeze a bit of optimization out of using Metal directly, but I think it's a more than viable approach to start with Vulkan/MoltenVK as a target, and add a Metal branch to the renderer when capacity allows (although you might never feel the need)
cess11 2y ago
Over the last few years I've had two applications that tended to rot after a week or two running, one is Firefox, which I still use for political reasons, and VS Code, the only Electron thing I've used for more than a few hours. The other being MICROS~1 Teams, which doesn't play nice with my window manager, tries to force me into identifying myself to join some video chat for a bit, and prefers to hang rather than shut down when asked nicely. Instead I join chats without video support. This is my problem with Electron applications. I'd be fine with them gobbling up a few GB if they were stable.
zamalek 2y ago
> In my mind, if you're someone who types in HN comments in a rage because your text editor WebGPU exists. It works with Metal. Vulkan could have also worked and MoltenVK would have bridged it to Apple. No, this is just like every other project that only works on MacOS: a mentality I really can't comprehend or explain.
- pjmlp 2y ago
  Developed for Web browsers, targeting managed languages, and hardware specifications from 2015.
  - zamalek 2y ago
    The reference WebGPU implementation is in Rust. It's what Bevy, and many other Rust game engines, uses. All discoverable with 5 seconds of google.

jonhohle 2y ago

Or… use one of the existing cross platform toolkits that have existed for decades. Text Editors, traditionally, did not require shaders to run or be performant, and not require entire systems worth of RAM.

MR4D 2y ago
Out of curiosity, how many of them run at 120 FPS? (honest question - I've never looked into it myself)
- forgotpwd16 2y ago
  This is the first time I see FPS mentioned for a text editor. Is this something that matters or just an pointless metric utilized as selling point?
  - SomeRndName11 2y ago
    Well it may have effect on ergonomics. Some people claim they cannot use 60Hz monitor after trying 144hz.
    - NekkoDroid 2y ago
      Well, that is usually refering to some form of "simulated fluid motion", not new characters appearing and disappearing. The only case where that kinda fluid motion would matter is when you have text scrolling by at semi-fast speeds.
      - ffsm8 2y ago
        I count myself among the people that would consider >60hz necessary. For me, it's animations, especially if I'm dragging a window or just the mouse. On 60hz it's nauseating if I'm paying too much attention to the window I'm moving. It's goes completely away around 90-100 Hz (at least for me)
        LoganDark 2y ago
        I've had the privilege of using a merely 90Hz display and the difference is still incredible. It gives me input feedback much faster so my brain does not have to do as much buffering/prediction, everything feels a lot more direct. One would think a measly 5 milliseconds wouldn't amount to much, but for input feedback it absolutely does. I do not suffer from nausea or motion sickness of any kind arising from computers or visuals in general, but I can still easily tell the difference between a 60Hz and 90Hz display. A few months ago I had the privilege of checking out the 120Hz displays on the new MacBooks and they're amazing.
        NekkoDroid 2y ago
        I'd still say that draggin a window would count as a "simulated fluid motion". Maybe not something you'd immediatly think of, but its still trying to convey the sense of motion. Just text appearing and dissappearing isn't something I personally could categorize ass the same type of animation. And I also count myself as someone who considers 120 at least necessary (on the primary monitor)
  - freqmod 2y ago
    Fps in itself is not important, but it is a substitute for input latency, and if your keystrokes start lagging it feels sluggish. At least historically electron based editors (like atom) has been feeling significantly more sluggish than sublime text or vim with a decent terminal emulator.
    - forgotpwd16 2y ago
      For terminal emulators comparisons at least the metrics used are latency and throughput. Now those plus times to do operations (load file, search & replace, etc) wouldn't surprise me to be the comparison metrics for text editors. FPS though feels weird.
  - sunshowers 2y ago
    As far as I can tell, graphics pipelines often use frame buffering. The quicker the next frame can be drawn, the faster it feels.
    - adastra22 2y ago
      GUI apps like text editors don’t redraw frames every update cycle.
- adastra22 2y ago
  The question doesn’t make sense. They don’t rerender the buffer every frame. I assume zed isn’t doing that either as it would be horribly inefficient. I presume what is meant is that it can handle a redraw fast enough to be in the next frame. In which case the answer is: all of them. Drawing text is not the bottleneck for a GUI program, unless you have a god awful browser stack as your rendering engine.
  - LoganDark 2y ago
    > I assume zed isn’t doing that either as it would be horribly inefficient. What are you supposed to do instead? Zed uses the GPU. It's not making calls to retained-mode widgets to individually reposition them, nor is it blitting into a buffer using the CPU. It's using the GPU which eats pixels for breakfast. You've been able to rerender the entire screen each frame for over a decade - just look at Windows 7 Aero, which ran on the laptops of 2009 for the exact same reason: it used the GPU!
    - zozbot234 2y ago
      Rerendering each frame is wasteful because it keeps hardware from reaching deeper power-saving states. This includes the CPU, GPU and even the display, due to technologies such as FreeSync. On modern hardware, even removing the blinking cursor has been found to save quite a bit of power, by eliminating needless screen redraws.
      - justinclift 2y ago
        > ... even removing the blinking cursor has been found to save quite a bit of power, by eliminating needless screen redraws. Hadn't heard of that before, but it makes sense now you mention it. :)
      - LoganDark 2y ago
        Zed only rerenders the window each time it changes (and also for about a second since the last interaction for reasons[0]) but every time it rerenders the window it does rerender the entire window and not just the area that changed. That's what I thought GGP was calling horribly inefficient. [0]: https://zed.dev/blog/120fps https://zed.dev/blog/120fps
- jethro_tell 2y ago
  Honest question. What could you possibly do with a text editor at 120 fps that you can't do at 15 or 30? I can't think or type that fast and I can't read scroll back that fast either so I can't wrap my head around needing something like that.
  - ajross 2y ago
    > Honest question. What could you possibly do with a text editor at 120 fps that you can't do at 15 or 30? More-honest-than-it-should-be answer: sell a product to Apple-ecosystem developers trying desperately to find something to justify the $3k they want to spend on a new MBP. (Typing this very comment in emacs running out of the Linux VM on a mid-range chromebook attached to a 30 Hz 4k television, btw. Come at me, as it were.)
    - jethro_tell 2y ago
      Heh, rocking a self built tmux/vim setup her myself, but even still I don't think I'm so cynical to think the only reason is for the marketing speak. I assume they have a reason, I just can't guess whatnot is.
      - ajross 2y ago
        I'm... absolutely that cynical. 120 Hz displays and the horsepower to drive them are the golden boutique speaker wire of the Gen Z tech set.
        Dylan16807 2y ago
        Oh come on. Fancy wires do nothing. 120Hz makes motion much smoother. It also reduces latency. Those make a big difference in many video games, or even just moving my mouse around and having it not skip two inches at a time. Your cynicism over 120Hz should match your cynicism over 4k.
        jethro_tell 2y ago
- whazor 2y ago
  Chrome supports 120Hz+ https://www.testufo.com/browser.html https://www.testufo.com/browser.html It also seems like you can configure VSCode to go faster: https://stackoverflow.com/questions/52230196/vs-code-is-visibly-not-running-over-60fps-on-144hz-monitor https://stackoverflow.com/questions/52230196/vs-code-is-visi... But honestly, 'responsiveness' should come from not blocking the main/UI threads, and rendering in the right order of importance.
phendrenad2 2y ago
If you want a shaderless text editor, just use NotePad. But the world has moved on and people like their text to look nice.
jamil7 2y ago
Cross platform toolkits, more than other software components incur massive tradeoffs. They’ve written one themselves, tailored to their needs and open sourced it along the way. I guess I don’t see the problem here. If one that’s existed for decades fits your needs better then use that.
- jauntywundrkind 2y ago
  Wgpu seems very very well loved & supported, is one of the most successful comings together of the graphics world in ages. I'd love to hear some actual critique of it, hear what people think are shortcomings, because it feels to an outsider like this is the fantasy land, that we're living in the better place now. https://github.com/gfx-rs/wgpu https://github.com/gfx-rs/wgpu
  - auggierose 2y ago
    Well, it's Rust. I am using TypeScript. I guess I am sticking with Electron. Maybe WebGPU can help me out.
  - littlestymaar 2y ago
    What I find interesting is that kvark, the open source contributor that made Linux port possible was the main developer on wgpu at Mozilla, yet he decided to build an alternative [1] to wgpu that he used for zed. I wonder what's the rational for that. [1]: https://github.com/kvark/blade https://github.com/kvark/blade
    - jauntywundrkind 2y ago
      Dzmitry gave a talk at a rust gamedev meetup on Blade. This ain't my turf so apologies for inaccuracies here. It appears to be a fairly novel attempt to write a graphics library with a semi conventional looking pipeline, that under the hood ends up eskewing a lot of the Vulkan concepts. Instead of per object contexts, it uses global contexts to do most work. Instead of taking resources and binding them into descriptor sets to use across pipelines (tracking state), Blade kind of recreates resources on the fly, lets them get used, and disposed of them. Kind of interesting philosophy of a complex binding model in Vulkan/WebGPU vs a more direct diy render model? https://www.youtube.com/live/63dnzjw4azI?si=KzLPm-gBX0gDKq7H#t=12m45s https://www.youtube.com/live/63dnzjw4azI?si=KzLPm-gBX0gDKq7H... Zed tool this work as an outside contribution. Maybe that someone did the work was good enough. I'm not sure what would make Blade a better match or not, vs wgpu-hal.
Iwan-Zotow 2y ago
> Text Editors, traditionally, .. and not require entire systems worth of RAM. Emacs is looking at you

nemomarx 2y ago

I suppose ideally you'd want it to be written on Linux first, if you're that kinda person - but the market is probably on Mac?

m463 2y ago
I remember reading a long time ago (think pre-intel macs) that game developers never developed for macs. However if they did, the games would sell because the mac people wanted games and there were so few available they would buy anything. problems of a closed ecosystem.
- thfuran 2y ago
  Circa 2000, a lot of big name games actually were released for Mac. Heroes III, StarCraft, and Diablo II, for example, all got Mac releases.
- wmf 2y ago
  Because Macs are expensive (in absolute terms) Mac users are a self-selected group who are willing to spend money. Linux users have high standards and are not willing to spend money. For a text editor in particular Linux is going to be the toughest market because it's already pretty saturated.
- pjmlp 2y ago
  How do you think iDevices games are developed?
from-nibly 2y ago
Doing it on Linux would make people ask "why isnt it on my distro" a LOT sooner. Thus adding complexity while you are trying to prove the concept.

duxup 2y ago

Someone has to pay for it, time, money, wait for it whatever. I love working with technical people who ask why and think about more optimal paths. On the other hand I'll listen to the same folks complain about some random app being stinky (I don't disagree) and wonder "Yeah but you going to pay more for that burrito so that company can hire folks to write it natively on every platform?" No you're not ... I know our customers at times aren't willing to pay / wait for the optimal path, and their customers aren't, so I get it.

NoraCodes 2y ago

> In my mind, if you're someone who types in HN comments in a rage because your text editor (VS Code) eats up 200+ MB ram, you don't get to cry about Zed not being supported on Linux from day one, because you can't have your cake and eat it too - if you want it on your platform, you gotta wait for the shaders to be written. This is certainly one takeaway. On the other hand, this very blog post points out that a community member, Dzmitry Malyshau, did the work to get the program working on the OS he uses. Malyshau does not work for Zed, which is a for-profit company; as far as I can see, he gets nothing out of working on Zed, except that he and other Linux users get to use it. Perhaps, rather than characterizing Linux users as whiny, we could take away the idea that many Linux users are willing to put in quite a lot of work to make things better for each other.

weinzierl 2y ago
"Perhaps, rather than characterizing Linux users as whiny, we could take away the idea that many Linux users are willing to put in quite a lot of work to make things better for each other." ... and that even if it means signing away their rights in a CLA to a for profit company. This is on another level than contributing to the Linux kernel that is GPL2 plus practically not relicensable because of the multitude of copyright holders.
justinclift 2y ago
> Perhaps, rather than characterizing Linux users as whiny, we could take away the idea that many Linux users are willing to put in quite a lot of work to make things better for each other. That's more an "Open Source" thing rather than Linux specific. A personal case in point was when I got Mellanox adapter support officially added to FreeNAS (now TrueNAS) because that's the adapter brand I had and needed it to work. Not a super huge effort as the FreeBSD driver worked (so just needed porting), but the integration process and follow up testing/advocacy/etc work wasn't exactly trivial either.

hvis 2y ago

MoltenVK is also a thing. Whatever small translation overhead it incurs is probably not that important for a text editor. And then you get a cross-platform API: not just Linux, but Windows as well. Maybe also other more niche OSes as well.

skohan 2y ago
Molten VK is amazing. When I started working with it, I was expecting a lot of caveats and compromises, but it's shockingly similar to just using Vulkan that you can easily forget that there's a compatibility tool in play. Probably you can squeeze a bit of optimization out of using Metal directly, but I think it's a more than viable approach to start with Vulkan/MoltenVK as a target, and add a Metal branch to the renderer when capacity allows (although you might never feel the need)

cess11 2y ago

Over the last few years I've had two applications that tended to rot after a week or two running, one is Firefox, which I still use for political reasons, and VS Code, the only Electron thing I've used for more than a few hours. The other being MICROS~1 Teams, which doesn't play nice with my window manager, tries to force me into identifying myself to join some video chat for a bit, and prefers to hang rather than shut down when asked nicely. Instead I join chats without video support. This is my problem with Electron applications. I'd be fine with them gobbling up a few GB if they were stable.

zamalek 2y ago

> In my mind, if you're someone who types in HN comments in a rage because your text editor WebGPU exists. It works with Metal. Vulkan could have also worked and MoltenVK would have bridged it to Apple. No, this is just like every other project that only works on MacOS: a mentality I really can't comprehend or explain.

pjmlp 2y ago
Developed for Web browsers, targeting managed languages, and hardware specifications from 2015.
- zamalek 2y ago
  The reference WebGPU implementation is in Rust. It's what Bevy, and many other Rust game engines, uses. All discoverable with 5 seconds of google.