This Developer Voices podcast interview digs into the juicy details of building a graphics engine in Rust through the lens of a purpose-built programming language made for graphics pipelines. This language, Graphene, is built on top of the Rust language and supports both JIT and ahead-of-time-`rustc`compilation of reusable image editing pipelines down to standalone programs (like full screen apps or CLIs akin to ImageMagick) and embedding in other apps like games or websites. And built on top of that language/engine, we talk about how our open source Graphite ( https://graphite.rs/ ) editor is being built to offer a credible alternative to creative apps like Photoshop and Inkscape.
In short, we're building an approachable, artist-friendly graphics editor that allows technical users to dig into its underlying technical details. Instead of picking one focus—like vector, raster, painting, photo processing, or animation—we're generalizing the technology and building something that's more like a "game engine" for universal graphics processing, where artist-friendly editing tools act like the "coding environment" or "IDE" for the underlying graphics programming language. Artists use industry-standard workflows to draw their artwork, and Graphite automatically sets up the Graphene node graph "code" behind the scenes for rendering their creations.
If your interest is piqued in languages/compilers, graphics programming, or rendering techniques and you're looking for a summer internship, applications are open for GSoC 2025 ( https://graphite.rs/volunteer/guide/student-projects/ ) working with us to build a better Graphene and Graphite, especially focused on the infrastructure for GPU-accelerated raster rendering. Get in touch (Discord is best) to tell us your background if that's of interest. We'll especially be prioritizing applicants with a languages/compilers and low-level GPU (WGPU, Vulkan, OpenGL, etc.) programming background. Even if you're not looking for an internship, but you can lend a hand with a compilers/graphics/game engines background, this is the area we are most bottlenecked on so your open source contributions would go tremendously far in helping us achieve our mission to recreate Blender's success, but in the 2D creative software domain.
This thread, which OP posted before I had gotten the chance to submit to HN, was given a very unideal title and gained no traction as a result. I think the deduplication system prevented me from submitting. But I just tried again and I've successfully done so: https://news.ycombinator.com/item?id=42747192 so on account of this thread going unnoticed due to its title, I'm considering this thread abandoned and I'd encourage the mods to do the same (if deduplication or something else is in order). Thanks.
Graphite is a 2D graphics editor written in Rust aiming to develop into the go-to alternative to Gimp and Inkscape. Right now it's a vector graphics editor and in 2025 will be growing into a raster editor for photo processing and image manipulation. Its unique feature is the node graph which gives more control over content creation and rendering, turning your artwork layers into fully-fledged programmatic systems that can operate on dynamic data.
This post now summaries our year growing and maturing the editor throughout 2024 and covers our plans for 2025, which I believe will be the year it really takes off.
Thanks, we'd love to assist you in getting involved with contributing to our project! It's something we take pride in, making it more accessible than most other open source projects to begin contributing to. Come join our Discord (link is on the website home page) and introduce yourself like in your comment here. Cheers!
I believe that's plausibly within the range is possible outcomes— which isn't true for any other project like Gimp, which has had its window of opportunity rise and then set forever.
First in the sense that there's nothing in the industry that's a real product. Certainly there are various experimental concepts people have made as a hobby in a limited capacity, but they don't really count as generally useful tool suites. There's nothing even from the commercial software side of the industry either, which I find surprising. But it gives our project an advantage.
We will have a large variety of filters and a subset of them will be implementations of all the SVG filters. Separate to our regular raster render process that's used for displaying content to the screen, we'll have an SVG render process used for exporting the graph data to an SVG file. That process will be specifically designed to preserve the purity of the graph data representation such that it encodes all possible operations in the SVG format directly, and resorts to progressive degradation as required to approximate things SVG can't natively represent. That might mean rasterizing some unsupported raster filters, but the ones SVG supports would be used natively.
Indeed, it's weird that nobody has brought node-based editing to regular image manipulation before our project, but that's our goal with Graphite. With the equally important goal of making the node aspect optional for users by building such capable tooling that it can abstract away the node graph for all conventional image editing use cases, allowing users to work purely with the WYSIWYG tools that secretly manage the node graph behind the scenes. Until they're proficient enough with the traditional tools to start learning the power of node-based editing.
That said, we've been building our engine so far with a focus mostly on vector editing. There are some raster nodes but they're pretty limited right now (no GPU support yet, more engineering to do until that's production-ready). The raster compositing and image manipulation nodes + tools + infrastructure will be a big part of the focus for next year on the roadmap (https://graphite.rs/features/#roadmap).
Ah yes, you made me realize we could check if the node graph isn't open and tell the user to report a bug in that situation, which must have arisen from a tool or other WYSIWYG aspect of the program causing a node graph error. But we wouldn't show it if it arose from the user just noodling around with the nodes. That's a good idea that'll be worth us implementing, thank you for the suggestion.
You can save the document and reopen it later just like in any other program. You might not be able to reproduce the graph validity error anymore because we fixed the specific bug you encountered. The input hints bar at the bottom shows what buttons you can press in any context, but that's a good idea to mention it in upcoming tutorials because I've noticed that users tend to ignore it. Hover tooltips and the app menu also both display shortcuts, which are worth pointing out in future tutorials as well. Thanks for that suggestion.
We have this for crash reports. Perhaps that's a good idea to add a menu button for reporting other bugs. Do you have suggestions as to how to make that discoverable?
Yes, that should never happen. If you ever encounter that, please report a bug describing the situation in which it occurred. The Brush tool bug was fixed yesterday, so that particular one shouldn't happen anymore.
Thanks for the feedback. What you've encountered is a type error— basically a programming language's compiler telling you that your code is invalid. It's not a bug per-se, although sometimes it is caused by our nodes not being as general as they should be. We just fixed an issue where the Stroke and Fill nodes only applied to vector data but didn't apply to group data (where the group contained one or more vector data). Those kinds of problems, when sensible, should probably get issues filed against them.
The red error message does tell you where to look:
> Check for error details in the node graph, which can be
> opened with the viewport's top right _Node Graph_ button.
So in the top right of the viewport, and it's the button labeled "Node Graph". Is it possible your window was very small and the button got scrolled out of the way by other buttons? I'm open to feedback about how you may suggest improving the text of that message. It would currently be hard to make that dialog more visual or interactive, unfortunately, but that'll be something worth building towards improving in the future with improved diagonstics all around.
Update: the issue with following what was shown in the tutorial is now fixed. Now the Fill and Stroke nodes apply to the vector contents of group data, which was the problem. (We made Circular Repeat produce a group of vector shapes to properly preserve styling information like gradients, which was why it broke.)
That's all definitely in-scope. If you'd be motivated to contribute it, there should also be nothing that's really blocking it right now if you're willing to dive into the implementation details. Please join our Discord and let's talk about it more.
1. Please see https://news.ycombinator.com/item?id=41854076
2. Yes, you got it! That's very much something we are building towards, and you hit it on the nail in describing how that will work and the utility it will provide to people across many industries from game dev to backend services.
Krita is a painting application. Graphite is a vector editing application. There is currently no overlap between the two apps. We intend to eventually build a painting application workflow, but that isn't something we're focused on yet and we'll likely prioritize other area first because Krita is a competent tool for painting already, which digital artist should use for that workflow until we someday have the time to build something even better.
Feel free to drop by our Discord and go into more detail about this. I think we may need to discuss it for me to understand exactly what you're describing.
In short, we're building an approachable, artist-friendly graphics editor that allows technical users to dig into its underlying technical details. Instead of picking one focus—like vector, raster, painting, photo processing, or animation—we're generalizing the technology and building something that's more like a "game engine" for universal graphics processing, where artist-friendly editing tools act like the "coding environment" or "IDE" for the underlying graphics programming language. Artists use industry-standard workflows to draw their artwork, and Graphite automatically sets up the Graphene node graph "code" behind the scenes for rendering their creations.
If your interest is piqued in languages/compilers, graphics programming, or rendering techniques and you're looking for a summer internship, applications are open for GSoC 2025 ( https://graphite.rs/volunteer/guide/student-projects/ ) working with us to build a better Graphene and Graphite, especially focused on the infrastructure for GPU-accelerated raster rendering. Get in touch (Discord is best) to tell us your background if that's of interest. We'll especially be prioritizing applicants with a languages/compilers and low-level GPU (WGPU, Vulkan, OpenGL, etc.) programming background. Even if you're not looking for an internship, but you can lend a hand with a compilers/graphics/game engines background, this is the area we are most bottlenecked on so your open source contributions would go tremendously far in helping us achieve our mission to recreate Blender's success, but in the 2D creative software domain.