Keavon

Thanks!

No support for custom scripts yet. But the whole concept is that we're basically building a WYSIWYG editor on top of a node-based compositor on top of a visual programming language (so that's three products in one, lots of work ahead for us!). The result is that the whole thing is a programmatic data pipeline and you'll be able to write custom scripts in both node and code form, then compose them into reusable pieces and pipelines. But since we're building three products in one, we have only been able to focus on the parts that matter most to get things working. Your request hasn't yet been one of those, but worry not, that's very much a core feature.

That's all far-future stuff that will let us continue to grow towards our larger ambitions further down the roadmap with a revenue stream that isn't purely dependent upon donations, which isn't sustainable on its own. It will always be a purely separate value-add that's not shoved down the throat of users— a subset of users will find that helpful and pay for the storage and most users won't care and won't be bothered about it. But we don't have any of that yet, and won't for a while.

It looks like that list tends more towards home-server self-hosted SaaS kinds of software rather than desktop apps. With our upcoming desktop app, and the fact that you can install it right now as a PWA, there's really no benefit from self-hosting. Your data is already client-side, so there's nothing for the server to do besides act as a CDN and send some tiny static assets. Unless people are going somewhere without internet, there's really no point in self-hosting the static files instead of using our CDN. Since we don't even have a server backend (except for a proxy to the Google Fonts API which we need to keep our API key private).

Thanks! I'll open it up to the community to suggest Graphite's inclusion in lists like that one but I'll abstain from doing that myself. I should mention that, at the present moment, the only category we'd appropriately fit under is the Illustrator alternatives. Next year we will be building towards raster editing as our next core competency, but vector editing is the only one we've focused on so far.

Thanks, those are really useful! Would you mind copy and pasting those into a comment in https://github.com/GraphiteEditor/Graphite/issues/1870 to help us keep track of those suggestions? I'd like to revisit them again.

It was a top contender when I was picking a GUI solution but it didn't meet the cut. Remember that this was 3.5 years ago. The decision to go with HTML/CSS was undoubtedly the right one and it'll continue to treat us well for the foreseeable future. But we are beginning to rewrite certain areas, like the node graph, in our own render stack because this streamlines the code best. And other widgets like histograms, color scopes, etc. will continue to be built with our own renderer. And then at some point, it will start making sense to begin gradually replacing other parts of our UI with the regular widgets like buttons and checkboxes with that system. Doing so will help us simplify things and make them more user-customizable, so plugin authors can affect the UI, etc.

Graphite is built to be a programmatic data processing pipeline that takes the form of a render engine and WYSIWYG editor. You'll be able to write custom code for every part of the system.

And because it's time for a fresh start. Sometimes you can't turn around a heavy ship, and that ship doesn't want to be turned around. It's easy to write a sentence like that, but once you actually think about it, how does an outsider with a good idea and a capability to execute on it somehow approach an existing project and decide to "take it over"? That would be neither viable nor would it yield a desirable outcome. We're building something fundamentally different from Inkscape that just so happens to eclipse it.

You remember correctly! Here's that thesis code <https://github.com/Keavon/Brush-Nodes>. You can ignore the readme since it doesn't talk about brushes and open the GitHub Pages site (or, I can just link it here: <https://keavon.github.io/Brush-Nodes/>). Then press Ctrl+1, Ctrl+2, Ctrl+3, or Ctrl+4 and reload the page after each. Be patient as it takes a couple seconds to load the page once a demo is chosen. That'll load the four brush demos:

- Ctrl+1: dotted stamp roller - Ctrl+2: bristle brush - Ctrl+3: diluted ink - Ctrl+4: ragged solid ink brush

This concept will be reimplemented in Graphite eventually. Maybe as a GSoC project.

The actual thesis write-up is here <https://digitalcommons.calpoly.edu/theses/2653/> in case you're really interested for some reason.

Roughly speaking, that's the plan, with next year's roadmap focused on raster (image and raw photo) editing. Currently, Illustrator would be the more appropriate comparison instead of Photoshop, because vector editing is the primary feature set we've built so far.

Everything will be using compute shaders for the foreseeable future. [WGPU](https://wgpu.rs/) abstracts that to work with WebGPU on browsers, DirectX/Vulkan on Windows, Metal on Mac, and Vulkan on Linux and Android. There may be opportunities to explore vendor-specific options like CUDA in the far future to leverage a further increase in performance, but compute shaders are portable and nearly as good.

Definitely! And in fact, that is on our [roadmap](https://graphite.rs/features/#:~:text=CAD%2Dlike%20constrain...). Maybe you could get involved instead of making something separate.

Upon rereading that paragraph, I suppose I didn't write that as clearly as I'd meant to. Blender is darn near perfect and there'd be no reason to replace it. So yes, as you figured out, I'm referring to becoming a second Blender but this time in the 2D realm: a generalist tool that uses actual innovation to catch up and then surpass its commercial competitors.

Right now, it's a custom HTML/CSS/TypeScript component system using Svelte built to minimize bloat. But since Graphite is a data-driven graphics app and render engine, we are planning to gradually rewrite our UI components as Graphite documents— allowing us to design the editor's UI within its own editor UI. Once that happens, we can probably drop the web dependencies— although we've taken pains to ensure our current web dependencies are very lightweight and performant. All the slow parts of Graphite are due to backend engineering shortcuts we've taken to enable forward progress, and those are stopgaps that are actively being worked on to be rebuilt into proper, high-performance systems.

I'm eager for that feature too! The node graph engine recently got the ability to represent that concept, so now I just need to find the time to design and build the UI for it. I utilize that feature a lot in other software so it'll be really helpful to have in Graphite as well.

Thanks for keeping things tidy! I'm more used to the Reddit side of the internet so I appreciate the help keeping to the norms here on HN.

That'd be because it's all CPU-based at the moment . So your 4080 is taking a vacation while your CPU hits the gym. That's obviously not ideal, but you'll have to trust me that it is due to long-term architectural planning reasons and not a blatant disregard for sensible development practices. Our node graph engine is really advanced—it's actually a scripting language built upon Rust and its type system—which will have some very sizable benefits once it's done being built. But right now, it means vital things like GPU compute have been blocked by a towering pile of other engineering work. But we've nearly completed those prerequisites and should be able to unlock GPU compute in the early parts of next year (this is also blocked on Firefox and Safari shipping WebGPU support, required to use compute shaders in the browser— and on us having the time to support Windows, Mac, and Linux builds via [Tauri](https://tauri.app/)).

In short, please be patient :) The app's architecture is designed with performance that'll make your CPU and GPU scream, but it's a big job building all of it. Especially for raster imagery, that's where a CPU-bottlenecked render pipeline is especially affected. But next year is the year we move on from vector graphics to raster once the GPU is utilized in the render pipeline.

Thanks for taking a look!

Thank you! The UI is all my design— and it's something I care deeply about making clean and approachable, so it's gone through thousands of hours of meticulous work.

We're using Svelte for component composition and reactive data binding, but all the actual HTML and CSS is written from scratch to match the UI design mockup and be as lightweight and bloat-free as it's possible to be. Since Svelte does its job at build time, we have very nearly zero frontend libraries that ship to users and would cause bloat.

I chose Svelte because it's similar in syntax to Vue, but more well-loved and it builds apps that run faster with its fine-grained reactivity model. We actually started the project with Vue and, about a year into development, we found its virtual DOM was causing too many garbage collection freezes when the UI got updated every frame by the Rust Wasm backend. (Porting to Svelte turned out to be a really good idea. Svelte is amazing.)

I started by choosing Vue.js because it nicely separates its HTML, CSS, and JS sections which theoretically would make it easier to someday rewrite the whole UI in a native Rust GUI framework, so the logic and layout wouldn't be intertwined based on the opinionated nature of the particular framework like React.

Building all the components from scratch was a practical necessity, even though component libraries are popular. We need full control over every aspect of every widget to suit our exact requirements for matching the UI design language I've built. Third-party libraries would be bloated and may lack the depth of customizability we require. I'm also very skilled at HTML/CSS development and have a not-in-house attitude towards other web code since I don't feel like the tradeoffs are worth it. So that's why I wrote all our components from scratch: customizability and maximal performance.

At the end of the day, the browser is just an operating system with a really robust GUI API. It just takes discipline to use it well and keep it lightweight. With that attitude, it's possible to make a very responsive, native-feeling UI that can actually beat out many truly native UIs in other apps. Just because it's an application in an OS that's in another OS doesn't mean it's inherently slow! People just associate it with the many sluggish web apps they're used to using from lazy web developers.

Introducing boolean path operations, a new gradient picker, layer locking, and more improvements.

Also see the Q1 progress report: https://graphite.rs/blog/graphite-progress-report-q1-2024/

Graphite is a new open source, Rust-based 2D design app combining traditional graphics editors with node-based, non-destructive procedural design workflows to bring actual innovation back to the world of graphic design. Our mission is to recreate Blender's success as the de facto tool in its creative discipline.

As the project founder, I'd be happy to answer questions here— ask away!

Thanks! If perhaps we spoke at GDC (taking a guess given the context), it was nice meeting you! (Keavon from Graphite here.)

We're in the process of refactoring a whole lot of code from the pre-node graph MVP implementation to the node graph version, while mainly aiming to avoid losing functionality in the process and not prioritizing new functionality quite as much yet. You can import or draw an image, though, and then right click in the node graph and search for certain effects and filters (similar to Photoshop's adjustment layers) and insert them in the chain of nodes. But to become actually useful, we need a bigger and more thought-out family of nodes combined with tools which automatically insert and update the nodes for you through the means of using the tools and doing lasso/marquee-style selections. Those are all a few months away on the roadmap, but it should be a lot more powerful and novel by then.

The file format will have its own built-in version control in the future, but I believe we are planning to use an ASCII representation so it could also theoretically be version controlled externally. The current `.graphite` files are entirely a temporary format. Once we finish the aforementioned refactor, we will design and implement a proper file format that ensures backwards compatibility (something the current files don't manage at all), it will be called `.gdd` (Graphite design document).

The web browser gives us an extremely frictionless development and deployment process. Our CI generates a fully deploy at a unique link for every commit which lets us open and test PRs with a single click. It deploys updates to users without needing to make them go through an updater. In these relatively early stages of our development process, the importance of the velocity that gives us cannot be understated. Plus, the ability for users to try it out in one second is quite helpful.

I've designed the whole architecture specifically to avoid the web UI "feeling like a web app" with the subtle latency of interacting with the site. I wrote all-custom UI components using the minimal amount of HTML and CSS to achieve the requirements instead of depending on an external component framework which always loves nesting dozens of `div`s inside each other to achieve what should be doable in one or two. And our highly-lightweight JS which calls into Rust (Wasm) lets it keep the slow logic out of slow JS. And we are using Svelte to move most of the frontend DOM management logic from runtime to compile time. This architecture really helps us keep performance levels as close as possible to feeling native despite using the web for its GUI rendering; and I believe it has succeeded at feeling responsive by comparison to most other web apps you use (even Slack, for example, which shouldn't be nearly as complex).

Web lets us build fast, deploy the latest version to users fast, leverage prevalent developer experience with HTML/CSS for creating GUIs, and avoid getting stuck in a box with Rust's currently-immature GUI ecosystem. That's the tradeoff we had to make early on, and it was a good decision. But we will eventually move towards a fully native version...

In the short term, we plan to use [Tauri](https://tauri.app/) which is sort of a hybrid between Electron and a native application. It uses the OS's webview to shrink the shipped binary to only a few megabytes and reuse shared memory resources with other webviews at runtime. It also runs all our Rust code natively instead of through WebAssembly so all the business logic in Graphite runs natively and only the thin UI layer becomes dependent on web tech for the GUI display.

In the long term, we plan to rewrite the entire GUI in [Xilem](https://github.com/linebender/xilem) which is the up-and-coming Rust GUI that I believe will finally get everything right, including performance (which is something many desktop GUI frameworks are actually bad it, and sometimes even worse than web). We'll still deploy a web version but at that point, it will become native-first.

Hopefully that roadmap and explanation of the architectural decisions clears up any worries about the short and long term state of our GUI.

Yes, that is very much the plan! I'm glad you asked because it's good to know people are needing that functionality in the real world. It'll probably start out with simple constraints but ideally turn to the constraint stack system like that in Fusion 360 and other CAD software over time. (I need to actually learn Fusion 360 so I have firsthand experience with that, though, plus then I could finally stop just lazily using Blender for all my 3D printing models.)

Plug-ins will (at least for the foreseeable future) take the form of writing custom nodes in Rust. That code will automatically compile to CPU and GPU (unless it requires an allocator or other things not possible on a GPU architecture). In the future that will extend to custom viewport tools, custom panels, etc. either through a traditional plug-in API or maybe even through defining all that in the node graph itself, since the graph is basically its own programming language.

We will probably also need to have bindings into a Python API since Python is so popular among technical artists. Precisely how that will be done is yet to be determined, since we have a lot to do before reaching that point.

Hi, Graphite creator and website author here. I 100% agree with you since I am very bothered by marketing copy that's painfully obviously written by a nontechnical marketing team, and I want to avoid that here.

But... I guess it's hard being on the other end when actually writing copy so I've failed to design text which can be highly terse and also descriptive of complex concepts without turning into paragraph-long explainers. I know what Graphite is in my head, but conveying that to newcomers is really challenging! But clearly I need to try again.

Is there any chance you'd be willing to reach out to me, ideally on Discord but email also works, and let me use you to test my copy to a fresh pair of eyes? Basically as a B.S. detector :) I'm currently working on a new revamp to the website with many new pages, so having a fresh perspective and some ideas how to make things more direct (but not necessarily overly technical, since it should be digestible to artists also) and less marketing-ey, I'd find that highly valuable.