Partially because Kvark, who has a long history in graphics programming, was enthusiastic about it, and has similar values of simplicity and effectiveness to our own. Mainly because our renderer is simple enough that we would have preferred to use Vulkan APIs directly, rather than going through wgpu. Blade is a thinner abstraction than wgpu, it's a bit more ergonomic than wgpu-hal, and it already supports our long term platform goals (Linux, Windows, and the web though via WebGL). So far, it's been running flawlessly, and it's been everything else that's the hard part!
wgpu (and webgpu more generally) is often presented as a very good choice for a cross platform low level graphics api. but it was designed around safety/security constraints to support the web, sometimes at the cost of performance (my understanding)
i heard somewhere this nice example: only big actors like AAA game engines would really benefit from the extra development effort it would take to use an even lower level api like vulkan/dx12 to squeeze the last 10% of performance that wgpu can't get you
so if i understand correctly, zed, just like a AAA game engine, wants to squeeze every last bit of performance from the gpu, and so wgpu is "too high level" for it? and blade is "like wgpu, but no design tradeoffs and lower level" so its a better fit? does that mean someday zed might reach for vulkan directly one day? im assuming dx12 is gonna be used on windows anyway?
Roughly yes, though I'd caveat it with the specific application of the GPU: simple, 2D, UI elements. We've already built an abstraction that allows us to fluently build up a design, and then burn it down into a collection of rectangles, paths, images, and such. We're not dealing with particle effects, lighting, 3D models, or anything else that game engines need to consider. As such, it's a lot lower cost for us to use something like Vulkan or DX12 directly. And, in fact, that was the backup plan if we didn't find something like Blade that we where happy with.
The "design of WebGPU" is a problem. It's designed for the web to be secure and sandboxed so the API design reflects that. This is not a good thing on desktop.
> The "design of WebGPU" is a problem. It's designed for the web to be secure and sandboxed so the API design reflects that.
The page you linked clearly states that wgpu-hal's API is extremely unsafe and skips many checks in order to reduce overhead. So while "secure and sandboxed" explains why wgpu wasn't chosen, it doesn't explain why wgpu-hal wasn't chosen.
The organization behind QT (QT Group) has pretty onerous licensing terms.
My understanding is that it's $3,950 per year just to develop using their libraries on your own computer if you ever in the future intend to commercialize your project using QT. Transitioning from the open source license to the commercial license is something you can do but it's not the happy path according to their FAQ.
My understanding is that some of the QT libraries or older forked versions of them are still completely under open source licenses but it seems like a very complicated situation if you have commercial aspirations with your project.
Something like Slint (Rust based but includes CPP and JS bindings) is not as comprehensive (yet) but it's more modern and the licensing terms are significantly more in line with software industry norms.
My interpretation is you can build commercial products with Qt for free as long as you can comply with LGPL. Mostly this means link dynamically (if closed source), only use LGPL components and give attribution.
Lots of GUI native, non-web libraries have been started in Rust, but they are VERY far from being close to what Qt supports. You may get closer using web based libraries (Tauri, etc), but I wouldn’t personally start web based desktop applications.
Exactly! There's always misunderstanding about Qt's license that I believe they should make the LGPL license clearer on their website. I believe many developers are struck down because they think it's not permissive enough where actually it's quite permissive.
Some of it might be misunderstanding, but complication of distribution may also play a role. Making sure that your application is correctly dynamically linked and packaged to run without issues across all supported platforms and configurations can be considerably more involved than statically linking depending on the toolchain in question.
Which on that note, last I knew getting Qt apps correctly stripped and packaged for all platforms was a bit of a bear. In particular I remember building Mac application bundles being messy.
This is true, but then again, these days, it's easy to look up at a popular open source Qt app and copy its CI recipes. For example, anyone that wants recipes for creating binaries for multiple operating systems can copy the GitHub workflows in my open source note-taking app: https://github.com/nuttyartist/notes/tree/master/.github/wor...
That said, I really think Qt should have a separate commercial license that is exactly like LGPL but allows you to link statically and costs much less (without all the enterprisy things).
One problem with Qt is that some modules are under the GPL and it is easy to end up inadvertently with a GPL dependency.
Also it seems the Qt company makes it confusing on purpose.
The only issue though is that Qt does not agree that mobile apps on app stores can use LGPL license due to anti-tivotization clause. Nevertheless they do have a somewhat reasonable pricing for small business of 500$ per year.
I think Slint is quite interesting, but it's licensing model is very similar to Qt, albeit somewhat more restrictive: The open source option is GPL v3 (not LGPL), and then there's commercial licenses, which yes, are cheaper - for now, for a start-up toolkit.
Pricing can change. Yes, there's a perpetual "Buyout" license for $5k, but they can probably just rename the product and claim it's a new one (or add a second product and add commercially relevant eggs to that basket; Qt has tried with things like "Qt for Device Creation" and "Qt for Automotive").
The open source option is not backed by a poison-pill protection like the Free Qt Foundation agreement either.
I know the people behind Slint, and I have a lot of trust toward them. But ownership can change, too.
Based on the discussion with our community, we added a clause in our CLA - https://cla-assistant.io/slint-ui/slint - to ensure that Slint will always be made available under an open source license as well as a royalty-free license.
"We believe that open-source software development and communities are the foundation for a healthy ecosystem of high-quality software, where everyone can learn, improve and give back. We commit to upholding this foundation and pledge by promising to continue to develop Slint in the open under an open-source license compliant with the Open Source Definition.
Further, we commit to provide a royalty-free license for those who develop desktop or web applications and do not want to use open-source components under copyleft licenses."
Slint is under three licenses: There The GPL for open source users, the royalty-free license for proprietary desktop application (which is free of charge), and the commercial license.
The royalty free is even better than the LGPL for Rust because rust doesn't support dynamic linking or even re-linking with object files.
The Qt Company sheds a lot of FUD on their licensing as an attempt to strongarm customers into paying for Qt. For a lot of companies, Qt's LGPL version would work just fine, but Qt will breathe down your neck trying to get you to switch.
> if you have commercial aspirations with your project
1. Nothing in copyleft licenses forbids you from making a living or receiving money.
2. Since the post was about writing an effect for KWin and your alternatives do nothing of sort… perhaps they aren't really valid alternatives, at least in this context.
Sometimes it's really obvious combinations of basic techniques.
And sometimes a graphics programmer does a handful of vector products or matrix operations and produces something that makes you go 'how the hell did you think of that?' when you look at it. Any time I see a sufficiently amazing shadertoy the odds are decent that the actual code for it is way simpler than I expect but still nothing I could've come up with.
You shouldn’t be downvoted for this. These are all examples of supplements that a complimentary medicine specialist at a cancer center could or would recommend for a patient in addition to chemo.
Different studies show different efficacies but these things are recommended to patients.
Yea it’s a chatgpt output, when it comes to this type of information Google search results are good for finding definitions of glutamine for example but harder to get specific lists of things
I highly recommend the book Life Over Cancer by Keith Block and reaching out to his cancer treatment center. They combine traditional chemo with complimentary medicine techniques that are in line with what you’re talking about here (low glycogenic diet, exercise, supplements). They are amazing.
