Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/GraphiteEditor/Graphite/llms.txt

Use this file to discover all available pages before exploring further.

Debugging a WebAssembly application has unique constraints compared to native development. Traditional debugger features like breakpoints and step-through execution are not supported inside a Wasm module, so most diagnosis relies on logging, comparison testing, and tooling purpose-built for Graphite’s architecture. This page covers the practical techniques that work best for tracking down bugs in the Graphite editor.

​
Comparing Deployed Builds

The fastest first step when investigating a bug is to determine whether it exists on master or only in your local branch. Graphite maintains two live deployments: Open both and reproduce the issue to narrow down whether it is a regression from master or something introduced in your changes. Use Help > About Graphite… inside either build to read the exact Git commit hash of that deployment.
All deployed builds — including dev, stable, and per-commit build links — are compiled with release optimizations enabled. This means some bugs that only manifest in debug builds (such as panics from bounds checks or debug_assert! failures) will be visible when running locally but will not appear in any deployed version.

​
Build Links per Commit

Every commit on the master branch gets its own hosted build through Graphite’s CI infrastructure. To access a build for a specific commit:
  1. Open the GitHub commits list
  2. Find the commit you want to test
  3. Click the comment icon on the right side of that commit row
This generates a direct link to the build for that specific commit. You can share these links with other contributors to reproduce environment-specific issues or to confirm that a fix is present in a given commit.

​
Bisect Tool

When you need to find exactly which commit introduced a regression, use the built-in bisect tool: 
cargo run explore bisect
This command opens the interactive bisect tool in your browser. The tool binary-searches through recent commits on master: you specify a starting date or commit hash, then for each candidate commit it provides a link to that commit’s hosted build. After testing the build you mark the issue as present or absent, and the tool narrows the range and repeats until the culprit commit is identified — typically in around 7–10 steps for a range of a few hundred commits. The bisect tool supports two search modes:
  • Find when a regression started — start from a known-good commit and search forward
  • Find when a feature was added or fixed — start from a known-bad commit and search for when it started working

​
Logging

Breakpoints are not supported inside WebAssembly, so print-based debugging is the primary technique for tracing runtime behavior. Open the browser developer tools (F12) and check the Console tab for output. Use these Rust macros in your code:
MacroUsageCommitted?
log::debug!("value: {x}")Temporary debugging output❌ Remove before review
log::error!("Unexpected state: {msg}")User-facing errors arising from a bug✅ Keep
log::warn!("Possible issue: {msg}")Non-critical problems that likely indicate a bug✅ Keep
log::trace!("Processing node {id}")Verbose internal activity logs, hidden by default✅ Keep
Trace logs are hidden unless you enable them via Help > Debug: Print Trace Logs in the editor menu.

​
Message System Logs

To observe the stream of messages flowing through the editor’s dispatch system, go to Help > Debug: Print Messages in the editor menu. There are two levels:
  • Only Names — prints the message type name for every dispatched message; low overhead and useful for confirming which code paths are being reached
  • Full Contents — prints the complete data payload of every message; more verbose but invaluable when investigating data correctness issues
This works well in combination with log::debug!() printouts: enable message logging to see the flow, then add targeted debug prints inside the handler where something goes wrong.

​
Node and Document IDs

In debug builds, you can inspect the internal IDs of nodes, layers, and documents directly in the UI:
  • Node/layer IDs — hover over a layer name in the Layers panel, or over any node or layer in the node graph, to see a tooltip showing its NodeId
  • Document IDs — hover over a document’s tab to see a tooltip with its document ID
These IDs are useful when cross-referencing log output with the visual state of the editor.
Use Window > Data to open the Data panel, which shows the live data value flowing out of the currently selected node. This is one of the most powerful debugging tools available: you can inspect intermediate values anywhere in the graph without adding debug nodes or modifying the network.

​
Performance Profiling

Having the browser developer tools open noticeably degrades performance in both debug and release builds. Close the developer tools panel when you are not actively using it — especially before recording performance profiles. For performance investigations:
  • Use the Performance tab in your browser’s developer tools to record and analyze profiles
  • Use debug builds for profiling; release builds inline and optimize away functions, which can make profiles misleading
  • The Firefox Profiler has some features not available in Chromium’s DevTools (such as better source map support and flame graph tooling) and is worth using for deep performance work
The live deployed web app and all CI build links use release optimizations. If you are trying to profile a specific scenario, run cargo build --profile dev locally to get a debug build with full symbol information.
For more about the editor’s architecture that you are debugging, see Editor Architecture. For understanding the node graph execution layer, see Graphene Engine.

Build docs developers (and LLMs) love

Get started for freeTalk to us