Keavon Chambers
a708a54492
* Add rank polymorphism node audit classifying all 271 nodes
* Implement StaticType for Item<T>
* Generate Item and mapped List wire variants for nodes declaring an Item<T> primary input
* Migrate nine nodes to Item element-wise kernels, dissolving the blending trait boilerplate
* Document the Item kernel implementation and staging plan
* Route Item<Vector> through TaggedValue::TypeDefault
* Add executor integration tests covering the Item and List wire variants
* Collapse element-wise Item/List wire pairs to the List form for conversion insertion
* Migrate sixteen vector modifier nodes to Item element-wise kernels
* Migrate Sample Image, Extend Image to Bounds, and Dehaze to Item element-wise kernels
* Fix bevel_with_transform test to actually exercise the transform attribute
* Implement From<T> for Item<T>
* Register PromoteNode rank adapters wrapping bare values into Item wires
* Insert PromoteNode adapters for Item/List wire pair fields in the preprocessor
* Define a real promote node backing the PromoteNode registry identifiers
* Zip ranked Item connectors by frame slot in the mapped element-wise variant
* Register ItemToListNode singleton raise adapters
* Resolve Item wires against List connectors by inserting promotion adapters at construction
* Rank the Offset Points distance connector and prove mixed-rank resolution end-to-end
* Implement Clampable for Item and List wires with per-variant clamp bounds
* Rank the Round Corners radius connector, exercising hard bounds on a ranked wire
* Implement ApplyTransform for Item
* Add Item wire implementations to the Transform node, keeping rank-0 chains rank 0
* Detect element-wise nodes by lazy primary connectors declaring Output = Item
* Convert Transform to an Item kernel with ranked parameters, delivering the broadcast milestone
* Rename Apply Transform to Bake Transform, baking item transforms on Vector, DAffine2, and DVec2
* Promote bare wires onto Item connectors at resolution via WrapItemNode adapters
* Rank the numeric, vector, and boolean parameters across the migrated element-wise nodes
* Rank the enum, integer, and seed parameters, registering their rank adapters via a consolidated macro
* Amend the audit with the DashPattern value type resolution
* Migrate the string family to Item element-wise kernels
* Unwrap Item wires into bare legacy connectors at resolution via UnwrapItemNode adapters
* Shadow owned node parameters in bodies instead of mut in signatures
* Migrate the math family and string measure nodes to Item element-wise kernels
* Convert the comparison and clamp nodes to Item kernels, dropping unreachable &str rows
* Flat-map expander kernels returning List under the mapped variant's frame
* Migrate the expander nodes to Item kernels flat-mapping under the frame
* Remove the unused peel_list helper
* Rank the raster adjustment and blending kernels, recontextualizing shader nodes onto an Item stand-in
Migrate the 16 adjustment nodes, Mix, Color Overlay, and Gradient Map from whole-List kernels to rank-0 Item kernels, letting the macro derive the List-mapped (zip) variants. Move the Adjust and Blend per-element seams off List onto the element types (add the Raster<CPU> impls, drop the now-dead List impls).
Shader nodes keep their bodies verbatim: PerPixelAdjust re-emits the identical kernel against a transparent no_std Item stand-in, so every Item<T> connector and .element() call resolves to a zero-cost identity on the GPU while the uniform buffer stays bare repr(C). The macro peels Item off ranked uniform params, wraps the fetched texel and uniforms at the entry point, and unwraps the result. This drops the shader_node/Item incompatibility guard. Register rank adapters for the adjustment enums.
* Update the rank polymorphism roadmap for the landed shader-node and adjustments chunk
* Rename the GPU Item stand-in to ShaderItem, aliased as Item at its shader-node import sites
* Flip the vector shape generators to emit rank-0 Item<Vector>
The shape generators (Rectangle, Circle, Ellipse, Arc, Spiral, Polygon, Star, Arrow, Line, Grid, QR Code) each produced exactly one shape wrapped in a singleton List<Vector>. Emit Item<Vector> directly so they connect to the rank-0 content connector of the migrated Transform node. Downstream List consumers receive the value through the existing Item to List promotion.
Relax the element-wise validation so a `()` (generator) primary may return Item<T> without being element-wise. Adapt the Repeat on Points test, which still takes a List content connector, by raising the generator's Item output through a singleton wrapper node.
* Parse ranked Item<T> parameter defaults against the bare element type
A ranked `Item<T>` parameter's default value is a bare, unranked `T` (promoted to the wire at resolution), but the preprocessor was handed the wrapped `Item<T>` type and could not parse the literal, flooding the console with warnings and dropping the defaults. Key the field's default_type metadata off the peeled element type for concrete ranked parameters, leaving generic `Item<T>` primaries and skip_impl nodes untouched.
* Parse an element-wise primary's scalar default against the bare element type
An element-wise node's primary reports its default_type as the List wire form so an unconnected primary defaults to an empty list. But when the primary carries a scalar `#[default]` (such as Root's radicand), that literal must parse as a bare element, not a List. Key the primary's default_type off the bare element type when it has a Default value source, keeping the List form otherwise.
* Add the DashPattern value type for stroke dash sequences
Introduce a rank-0 DashPattern value type (a Vec<f64> of alternating dash and gap lengths) so a stroke's dash pattern is a single frameable value rather than a rank-1 List<f64>. Register it as an auto-generated TaggedValue variant, parse its default from a comma or space separated string, and register its rank adapters. Not yet wired into the Stroke node.
* Rank the Fill and Stroke nodes element-wise and give Stroke a DashPattern connector
Migrate Fill and Stroke to element-wise Item<V> primaries (over Vector and Graphic element types) via a new element-level VectorItemMut trait, so styling one shape yields one shape and rank is preserved instead of promoting the input to a singleton List and emitting a List. The macro derives the List-mapped variant for genuine collections.
Wire the Stroke dash sequence to the new rank-0 DashPattern value type, collapsing the old content x paint x dash cartesian and dropping the IntoF64Vec trait. Update the stroke properties dash widget, the drawing tool, and graph-operation plumbing to read and write DashPattern, and migrate legacy F64Array, F64, and String dash inputs on document open.
Assign Colors stays a whole-collection node: each element's gradient position depends on its index among all siblings, which the element frame does not expose, so it keeps its List primary and the VectorListIterMut trait.
* Register rank adapters for the ranked Stroke enum parameters
The element-wise Stroke node ranks its align, cap, and paint order parameters as Item<StrokeAlign>, Item<StrokeCap>, and Item<PaintOrder>, but those enums lacked promotion adapters, so a bare default enum value could not be promoted to its Item wire and no Stroke variant resolved ("No construct found for node"). Register their rank adapters alongside StrokeJoin.
* Display Item wires in the Data panel without a List's ID column
Add a TableItemLayout impl for Item<T> and recognize Item wire types when introspecting graph data. An Item holds a single element, so it renders as a one-row table of the element plus its attributes with no leading index column, and it labels as its element type T rather than a List's T[]. Add ItemAttributeValues::get_any for the attribute widget dispatch.
* Register MonitorNode for Item wire types so the Data panel introspects them directly
Graph introspection wraps the inspected output in a generic MonitorNode typed to the wire. Without Item<T> monitor registrations, an Item<Vector> output could only be monitored after an Item to List promotion, so the Data panel captured and displayed a List<Vector> despite the connector being Item<Vector>. Register monitors for the Item types the element-wise nodes emit, and add the matching Data panel downcast entries.
* Color and double Item/List wires and cleave layer-stack connectors in the node graph
* Route wire color and rank through hidden nodes and refresh them on type changes
* Rework the DashPattern connector conversions with element-wise promotion and an explicit reducer node
* Rank the remaining value, context, aggregation, and transform nodes onto Item<T> wires
* Back DashPattern with a List<f64> so the Data panel can introspect its lengths
* Carry a single Item<T> through varargs so the Read context nodes emit Item<T> not List<T>
* Relax rank validation for aggregation shapes, add element adapters, and match variants by fewest promotions
* Rank the remaining bare and unnecessarily-List connectors across the node catalog
* Add Graphic::None and the FillChoice paint value, making colors and gradients plain values
* Rename GradientStops to Gradient and the legacy Gradient/Fill structs to LegacyGradient/LegacyFill
* Restore generator frame-from-params ranking to the roadmap as a planned stage
* Rename the ranked-field adapter identifier from PromoteNode to FieldAdapterNode to reflect its full contract
* Unload only the wires whose displayed style changed when types update
* Peel wire rank in the editor's semantic type checks so rank-0 layers are recognized
* Restore the whole-List Transform variant so rank-1 content wires resolve again
* Register the Item wire forms for the Memoize and Context Modification infrastructure nodes
* Give every ranked connector a field adapter and add numeric cast variants for legacy wires
* Key a ranked param's type default off its Item wire form when no literal default exists
* Inherit the layer's content value when splicing a node into an empty chain
* Migrate stale List-form TypeDefault inputs to the definition's current default
* Generate the mapped wire variant only when the element-wise node has a frame source
* Let a bare wire feed a List connector via a wrap-raise adapter, costed as two rank steps
* Add a zip companion to the whole-List Transform so ranked List parameters pair per slot
* Add the Sum, Average, Minimum, Maximum, Any, and All list reducers
* Convert the measure family to element-wise Item kernels per the audit classification
* Prefer the bare element value over the Item type default so ranked params keep their widgets
* Rename GradientStopsUI to GradientUI
* Split Fill's optional transform into a _has_transform bool and a ranked _transform matrix
* Rename the migration-only OptionalDAffine2 TaggedValue to LegacyOptionalDAffine2
* Flow byte buffers as Item<Resource> instead of List<u8> across the byte nodes
* Macro-generate the list-content wire variant, retiring the hand-written Transform-zip, Area, and Centroid companions
* Let ()-primary generators take ranked params and frame over them via the mapped variant, ranking Circle's radius
* Rank the vector shape generators' params to Item, adding a rank-aware input grab to the introspection harness
* Rank the value, color, and text generator params to Item
* Rank the raster, web-request, and context-reader generator params to Item
* Fix the repeat and brush test wirings left behind by the param-ranking sweeps
* Delete the vestigial Some, Unwrap Option, and Size Of debug nodes
* Delete the Attach Attribute node, folding its role into Write Attribute
* Add the Filter and Sort list companion nodes
* Guard the removed-definition migration swap target with a test
* Add the Box Corners value type in place of the rectangle corner radius list
* Split Text to Vector's per-glyph mode into a Text to Vector Glyphs node
* Rank the Combine Channels node's channel connectors to Item
* Make Map Points an element-wise node
* Delete the deprecated Upload Texture node
* Update the implementation roadmap to reflect the landed stages
* Let monitor introspection read rank-0 wires, locking in the layer coercion promotion path
* Prefer the rank-0 default when disconnecting a rank-capable input
* Make Path Modify an element-wise node
* Wrap node paths in a NodeIdPath newtype so they flow as a single Item
* Give Item<Raster<CPU>> a default so an unconnected Brush background resolves
* Stop the Brush node from setting layer attributes its paint operation doesn't produce
* Present-gate Flatten Path's adopted layer path like its fill and stroke
* Gate carried layer attributes on static column presence, not runtime values
* Give the remaining graphic Item<T> types a default so unconnected primaries resolve
* Dispatch a ranked param's Properties widget from its rank-0 element type
* Make Extract Transform an element-wise node, restoring the Origins to Polyline body
* Rename Flatten Path to Combine Paths
* Stamp Legacy Layer Extend's adopted layer path as a readable NodeIdPath
* Drop the dead List<u8> and List<NodeId> wire rows
* Rank Flatten Graphic's Fully Flatten toggle to Item
* Update the implementation roadmap with the endgame scope
* Make Combine Paths a reducer that collapses the whole frame into one path
* Stop type-converter nodes from carrying the source's unrelated attributes
* Format the Origins to Polyline regression test
* Wrap the Brush node's trace in a BrushTrace newtype so it flows as one value
* Make Switch a framed element-wise select, bundling whole collections
* Widen and align element-type coverage across the list and graphic nodes
* Register the compiler's cache chain pair for every ranked enum and newtype wire
* Fix wire colors for Passthrough outputs, bundled lists, and bools, and widen list wires
* Represent List wire types structurally with Type::List, replacing name-parsed rank promotion
* Treat scope and data fields as environment, rank scope wires as Item, and feed the render boundary through a context vararg
* Delete the vestigial Clone debug node
* Reinstate Upload Texture as an element-wise node and fix the GPU variants' scope executor and rank adapters
* Rename Combine Paths back to Flatten Path, deferring that rename to its own PR
* Deduplicate the promotion adapter registrations into the field adapter macro
* Rank Write Attribute's value connector to Item<AttributeValueDyn>, retiring the UnwrapItem bridge
* Vertical wire styling
* Store the editor layer path attribute as a bare NodeIdPath, not an Item<NodeIdPath>
* Rank Context Modification's features connector to Item<ContextFeatures>, dropping the dead memoize row
* Rank Path Modify's modification parameter to Item<Box<VectorModification>>
* Rename the field adapter node family to input adapter
* Drop the dead bare scalar rows from Context Modification's implementations list
* Move the dynamic executor's test module into its own file
* Drop the registry's unreachable bare rows for Memoize, the cache chain, and ConvertNode
* Materialize stored TaggedValues as ranked Item wires at the source
* Remove the bare-wire promotion and adapter machinery made dead by ranked value materialization
* Plant the input adapter for List-only inputs, composing position conversion from standard rows
* Consolidate Into/Convert conversions into the input adapter umbrella and rename the rank adapter identifiers
* Fix grouped layers gaining a phantom None stack element from the FillChoice default hijacking every List<Graphic> disconnect
* Enforce ranked node inputs in the macro, rejecting bare wire declarations
* Remove the unit Context => () machinery rows, leaving () purely as the no-primary sentinel
* Add a --signatures rank-audit mode to node-docs for the ranked-wire migration
* Remove the node-docs --signatures rank-audit mode now that ranked wires are enforced
* Migrate legacy no-color values on the Black & White, Color Overlay, and Empty Image color inputs
* Rewrite the element-wise accessor wire type at the primary input, not raw index 0
* Register the cache chain for Resource wires, replacing the lone hand-written Monitor row
* Gate the remaining Raster<GPU> registry rows behind the gpu feature
* Let List<DVec2> wires erase to ListDyn for the attribute reader and element counter
* Rename Extract Element to Item at Index, Count Elements to List Length, and Omit Element to Remove at Index
* Store paint picks as plain color/gradient values, removing the FillChoice value type
* Code review restructuring
* Sort by the consumed sort_key attribute or natural element order, adding the Sort Key node
* Remove the new list-combinator and reducer nodes to defer them to a follow-up PR
* Parse Fill and Stroke color defaults through the paint wire's Graphic element
* Emit ranked implementation-row default types structurally so their element TypeIds survive to default-literal parsing
* Exempt the deliberate no-paint choice from the stale List-form TypeDefault migration
* Migrate the legacy 4-input Fill directly to the split has-transform shape
* Upgrade the demo artwork
* Fix the valid AI review findings: Item eq/hash contract, table-era no-paint migration, quantize List rows, and other smaller issues
* Remove the rank polymorphism working documents
* Hash Item attribute values directly instead of debug-formatting them, speeding up cached evaluation
* Replace the data panel's dead bare-wire downcast arms with full coverage of the ranked monitor row types
* Derive PartialEq for Item now that attributes participate in equality
* Extend the data panel's attribute dispatchers with the newly supported scalar and choice enum types
* Add List monitor rows for the framed numeric conversion outputs so inspecting them resolves, with matching data panel arms
31 KiB
+++ title = "Year in review: 2024 highlights and a peek at 2025" date = 2025-01-16
[extra] banner = "https://static.graphite.art/content/blog/2025-01-16-year-in-review-2024-highlights-and-a-peek-at-2025.avif" banner_png = "https://static.graphite.art/content/blog/2025-01-16-year-in-review-2024-highlights-and-a-peek-at-2025.png" author = "Keavon Chambers" summary = "Graphite has come a long way in 2024. Read about the progress made and the plans for the upcoming year." reddit = "https://www.reddit.com/r/graphite/comments/1i3umnl/blog_post_year_in_review_2024_highlights_and_a/" twitter = "https://x.com/GraphiteEditor/status/1880404337345851612" bluesky = "https://bsky.app/profile/graphiteeditor.bsky.social/post/3lfxysayh622g"
js = ["/js/component/youtube-embed.js"] css = ["/component/youtube-embed.css"] +++
Another year has come and gone which has propelled Graphite—further than any year before—towards the ambitious goal of satiating the open source community's expanding appetite for an awesome 2D content creation suite that surpasses established choices in ease-of-use, powerful features, and affordability (at the unbeatable price of free).
In a world where the notion of software ownership seems headed towards extinction, the need has never been greater for an independent, community-built alternative to the vector graphics, animation, image manipulation, photo processing, and publishing tools used daily by millions of creators worldwide.
Graphite is and will always remain yours to keep, whether that's by running the lightweight, client-side web app (no signup, no cloud), installing the PWA on your desktop, self-hosting the builds, or downloading the soon-to-be-ready native app for your OS of choice (more news on that later in the post).
<style class="float-image"> .float-image + p { text-align: left; } .float-image + p > a { float: right; margin-left: 1.5em; margin-bottom: 1em; } </style>
Join me, founder and designer of Graphite, to see where the past year has brought us on this quest. And let me take this moment to thank our growing community for sharing my vision and showing support, both financially and by boosting the GitHub project page over the 10,000 star milestone just in time to celebrate the end of a productive 2024.
2024 development progress report
In 2024, Graphite grew from a promising tech demo into a by-and-large useful application for vector artistry and graphic design, equipped with its totally unique secret ingredient: nondestructive, procedural editing via a node graph. This was a year focused on iterating until a prototype became a polished product— at least by the standards of alpha-stage software. If you haven't tried Graphite recently, please take another look!
Improvements made throughout Alpha 3 (2024's release series) brought the formerly abysmal performance up to now-adequate levels and solved the vast bulk of instability with the once-numerous crashes and bugs. Advancements to Graphene, our bespoke node graph engine technology, has let us begin to support new rendering possibilities, introduce more helpful nodes, and remove restrictive limitations with common node combinations that previously were points of frustration. We also made big strides improving the tools used by artists for vector drawing with features like boolean path operations, snapping, layer selection history, quick measurement, gradient picking, and extensive usability-focused tweaks—both big and small—all throughout the editor.
This was also the first year of publishing quarterly development reports to the blog. We have aimed to keep them all visually interesting by showing the new features with looping video clip demonstrations alongside digestible sentence-long change summaries. Please let us know if you find this format valuable and worth continuing in 2025.
- Graphite progress report (Q1 2024)
- Graphite progress report (Q2 2024)
- Graphite progress report (Q3 2024)
- Graphite progress report (Q4 2024) will be published soon— stay up-to-date with the newsletter or RSS feed
Alpha roadmap update
Alpha 3 began back in February 2024 and we plan to declare the start of the Alpha 4 release series again in February after wrapping up the holiday development cycle and shifting gears for the big projects we plan to tackle in 2025. I'll expand on those goals for the upcoming year later in this article. If development keeps pace with plans, Alpha 4 may be the last before Beta begins as early as the start of 2026.
Google Summer of Code results
Our project had the fortune of being selected to participate for its first year as a mentoring organization in Google Summer of Code (GSoC). We were given the opportunity to welcome three student interns to the team as they developed significant contributions to our open source code base throughout the summer.
I would like to express my gratitude to Google for funding the program and its stipends given to our students. It has ushered in a great deal of talent to our contributor community. And even beginning right now, we are seeing proactive prospective students begin submitting code in anticipation of the 2025 program. We hope our organization is invited to return for the opportunity to mentor another cohort of budding talent, much like our 2024 students—Adam, Elbert, and Dennis—whose accomplishments far surpassed my most optimistic expectations.
Adam contributed an extensive evolution of Graphite's node editor. He introduced adjustment layers, editable nested graphs, and layer/node organization features that have upgraded the capabilities of the procedural editing environment, bringing it closer to my product vision. I'm delighted to announce that Adam has decided to stick around past the summer and join the core team. His continued development of the node editing systems to fully realize my design goals will make the editor magnitudes more powerful, and at the same time, easier to use. More on those plans later in the article.
Elbert built a new Rust library, Rawkit, for decoding and processing .arw files from Sony digital cameras, one of the most popular camera brands. Nikon, Canon, and someday all other formats are in scope for the future direction of the code. This library gives us the fine-grained control we require and will allow Graphite to begin its focus on digital photo processing in 2025 once several technical limitations are overcome and Rawkit is integrated into Graphite.
Dennis developed a range of critical improvements around the theme of performance. Before his contributions, working in Graphite was too slow for practical usability. Afterwards, it became fast enough to be useful in most scenarios (except when dealing with excessive complexity in terms of pixel or vector point counts— those known bottlenecks remain as future work). He made rendering and various nodes such as boolean operations faster, built profiling tools to aid in the continued quest for speed, and made changes adding to the robustness of the entire node engine. Lastly, he integrated the Vello high-performance vector graphics renderer to replace our SVG-based rendering method. This streamlines the rasterization and compositing that's involved in showing you the artwork in your viewport. Vello can be turned on from the editor preferences menu and will be enabled by default later in 2025 when browser support for the WebGPU API, which Vello relies on, becomes widespread.
Another part of the GSoC program was the Mentor Summit in October where I got to meet and share knowledge with open source maintainers from the other participating organizations. Hosted at Google's Mountain View offices, it was a weekend of talking tech and learning the lessons of open source project management from the seasoned veterans.
But I also managed to pass on knowledge in a subject I'm passionate about: design. I led a session titled "Well-Designed User Interfaces in FOSS Apps" in which 30-40 participants came to explore and discuss how the open source community can improve in this notoriously challenging discipline. The Mentor Summit was just one of the community events we took part in over this past year.
Community events
Outside of my daily routine spent coding, designing, and managing the project, I've also continued working to expand our community engagement and industry outreach. Members of the Graphite team met up at events during the year to represent the project and plant the seeds of future growth for our mission beyond the reach of the little pocket of the internet we call home.
Game Developers Conference
In March, accompanied by Oliver Davies, a personal friend/tech artist/contributor to Graphite's product design, he and I visited the Game Developers Conference (GDC) in San Francisco for opportunities to meet face-to-face with industry colleagues, as we did also the past two years.
We introduced Graphite to open source organizations like Godot and O3DE, caught up with Francesco and Dalai from the Blender Foundation, joined a roundtable panel on open source adoption in the games industry, and came together with the Rust Gamedev community for a physical meetup of game and graphics centric Rust developers. It was a treat seeing several people in-person for the first time whom, before, I'd known only online.
With March now just around the corner, I am definitely looking forward to the next conference. If you will be in town for GDC 2025 and would like to meet up, please get in touch.
Blender Conference LA
The next month in April, Oliver and I went to our second conference of the year: BCON LA, the first Blender Conference held in Los Angeles. We connected again with the Blender team and met many 3D/VFX industry professionals and prominent members of the Blender community over the two days of the event.
I also took to the main stage to present a lightning talk introducing Graphite to the community:
{{ youtube_embed(id="x3P5eYv11EU", timestamp=1603, title="BCON LA 2024 - Lightning Talks") }}
Graphite booth at Open Sauce
The month of June was particularly special because of Open Sauce, a convention and expo in San Francisco for makers and creators, and of course, open source projects!
This presented the perfect opportunity to host our own exhibitor booth and talk to hundreds of excited attendees with creative tech backgrounds over the two day show. The event was excellent for networking with fellow makers and a chance to meet an array of the guest YouTube creators including several from the digital content creation realm.
I designed the booth with the goal of becoming an inviting artist's space. Visitors could contribute doodles to the pair of LED-backlit dry erase boards, walk inside to talk with us about the project, and sit down to explore the app. This was a valuable chance to "playtest" the user experience with a steady supply of new people from a variety of backgrounds. I also learned how to refine our approach to communicating clearly what the product is and does.
Joining me again was Oliver to assist with the booth, as well as our new GSoC contributor, Adam, who flew up from southern California to help. In between the hustle and bustle, we put the face-to-face time to good use communicating the vision and planning many aspects of his node graph development.
Graphite booth at the Bay Area Maker Faire
And then when October rolled around, we did it again! Now located at a post-industrial waterfront venue across the Bay from San Francisco, the Maker Faire started with a Friday field trip day for local schools followed by a full weekend of general attendance.
The Maker Faire is ground zero for the Maker Movement. I grew up going each year as a kid. It was an era when consumer 3D printing was completely new and that was the only place one could discover—and obsess over—the technology. The Faire influenced my career path into engineering and the arts, so it's fitting that I would grow up to return and share an open source project, born out of that community spirit, for the next generation of creative young minds.
Attracting a more family-oriented audience than Open Sauce, it presented the chance to learn how approachable Graphite is even for kids. Doodling on the LED-backlit whiteboards flanking our booth was especially popular with that age range and brought in many passers-by. Of those who tried Graphite, I was blown away to see how some of our youngest visitors—down to the age of 6—were also the most capable and engaged using the product, diving in deep with barely any instruction. As the UI and product designer, this assured me that I have been on the right track so far. I believe now more than ever that my ambitious goal is achievable: creating the most intuitive and user-friendly professional graphics editor on the market.
Another exciting part of the Maker Faire experience was bringing together nearly the full Graphite core team in-person. Oliver and Adam came to help again while we were also joined by Dennis visiting all the way from Germany, conveniently coinciding with a vacation he had planned. We put our commute time towards deeply technical code architecture discussions and knowledge transfer.
Graphite is tentatively anticipating a return for Open Sauce and the Maker Faire again in 2025. Make plans to come and visit!
Looking ahead to 2025
There are so many plans that I'm eager to carry out to improve the clarity and capability of the experience Graphite offers our users. Some are small, and a few we will be working on for most of the year.
Desktop app
Starting out with our most in-demand request: a desktop app. This has been on our roadmap from the start but only recently it's begun making sense putting it at the front of the roadmap priorities. We hoped to complete it by the end of 2024, but that wasn't in the cards due to developer availability and the specialized skills needed to complete the task.
Now to get technical, the lazy option exists: chucking the whole web app in an unaltered Electron wrapper, but this is a technological dead end that I believe offers no value compared to a PWA. The value comes from offering an actual native app where the editor Rust code and GPU-accelerated rendering runs on a user's Windows, Mac, or Linux machine without browser overhead. Our use case of combining the web-rendered editor interface with the user's native-rendered artwork presents several unique challenges that our team has to overcome— individually on each platform. If you have experience with native development on Windows, Mac, and/or Linux, please get involved to speed up this effort! With our current resources, I am anticipating this will be ready for release around spring.
Animation
Next, the feature I am personally most itching to dive into developing is animation. I've been recently iterating on the UI design mockup for the Timeline panel which will support keyframing any desired node parameters. This new panel will seamlessly integrate into the existing graph-based, data-driven workflow and make it easy to create motion graphics paired with procedural generation.
Advanced procedural editing
It is now becoming time to delve into the next phase of making the node graph more powerful by introducing several key features:
- Lambdas: treating a node as a piece of data given to another node, so it can be run in a loop with varying parameters in each iteration.
- Instances: generalizing graphical data, transforms, and groups so that every layer is one or multiple instances, each with a unique transform. This will finally fix the long-lived limitation of layers lacking a proper pivot point.
- Lists: representing lists of data like vector points and segments in a spreadsheet. Formalizing the tabular data representation lets the node engine benefit from ECS-like performance gains by optimizing CPU cache utilization.
- Attributes: encoding properties (of points, of segments, of instances, of appearance styles, etc.) in columns on the tabular data. This will unlock Graphite to become as powerful as Blender geometry nodes which works based on the same design principle.
Raster graphics editing
Graphite has included a primitive kind of raster support for a while, mostly used for including reference images when creating vector content. Some raster nodes can adjust the colors of images, but there are no tools yet for selecting and drawing over parts of an image to make localized edits. Furthermore, CPU-centric bottlenecks slow down the editor when big images are in use. The GPU is not used by any nodes operating on pixel-based data.
Consequently, raster editing just isn't viable yet until tool and GPU node support arrives. The innumerable complexities would not fit in this section, but if you have a background in compilers or graphics programming, please hop on our Discord and ask about it if you're curious or potentially interested in helping. After the infrastructure parts are in place, we can begin building nodes that make localized edits (such as a masking node) and start developing tools including a fully rewritten brush engine and a mode for drawing marquee selections. I can't yet predict how far we will get by year's end with these interactive localized editing tools because it will all depend on how quickly the prerequisite technical infrastructure components come together. Part of that will depend on how soon the browser vendors ship universal WebGPU API support so it can be deployed beyond an experimental state in Graphite.
Graphite in education
A valuable discovery came out of exhibiting Graphite at the Maker Faire. I had conversations with several school teachers who were interested in using Graphite in their classrooms.
I was told that other web-based graphics editors are commonly blocked by the IT admins of school networks due to policies against visiting sites with ads. (Crazy!) Since Graphite is entirely ad-free and runs on Chromebooks, this presents an opportunity to focus on better supporting the education market. In fact, I have recently been watching Chromebooks account for a small but rapidly growing portion of our site's visitors which means some educators are teaching Graphite in their classrooms:
This was previously a user demographic that I didn't consider. My school experience never offered graphic design instruction. I had to teach it to myself, and when using school computers, I ran portable installations of remote desktop software to access the desktop creative applications on my home computer. That experience led to my selection of a software stack that would support web-based access to the Graphite editor for the sake of students like my past self, but my previous assumption was that teacher-led instruction would be years away.
Learning that there are educators who want to teach these skills directly to students was eye-opening. It could be an excellent fit: each teacher brings along dozens of users. A teacher can learn the app once and disseminate the instruction which saves us from needing pristine learning resources at this early stage. Then a teacher can find the most common sources of confusion and filter that feedback back to us for improvement. Compared to professional artists who can't always justify using alpha software, students are a less demanding type of user. And Graphite benefits from a generation of students growing up to continue using the app. It seems like a surprisingly good fit.
My goal in 2025 is to begin prioritizing specific resources for educators that might include:
- Pushing for development efforts that will improve performance to help the app run better on low-spec hardware. This benefits everyone else just as greatly!
- Reducing common pitfalls in the software that are especially likely to be encountered by inexperienced users.
- Putting more time towards creating learning resources and documentation to help instructors learn Graphite well enough to teach it and solve student issues.
- Collaborating with teachers to devise and develop a curriculum package that can be used in classrooms to teach specific skills.
- Creating an information page for educators to discover the project, learn how it suits their needs, access curriculum, and get connected with us.
If you are a teacher, or know one, who would be interested in adding this manner of STEM/STEAM instruction to your classroom, please get in touch so we can figure this out together.
Thank you for helping us help you help us all
By not being backed by investors or built by staff engineers or marketed by an agency, Graphite is an ambition that is constantly treading the line that borders the realm of impossibility. But thanks to your support, I am confident our efforts will prevail. 2025 is the year when all the pieces fall into place with a desktop app, competitive performance, features, and raster image editing. It will be the free software you can own (and love) that holds up against the software you have no choice but to rent (and put up with as it trains AI on your private work).
Ultimately, reaching critical mass might take one year. It might take five. That part is up to you. Momentum and resources are both scarce which means you, personally, have the opportunity to make an outsized impact.
If you choose to become a member, you are directly helping fund our expenses like conference travel and ordering T-shirts that keeps the volunteer team happy and motivated to code. Remember that "free software" doesn't mean it's free to produce, it just means someone else is paying for it if you aren't pitching in. We just added an option for donating directly without needing a GitHub account, so now it's easier than ever to contribute.
If you choose to volunteer, you lift our greatest bottleneck—time—and bring your unique skills to the table. There are opportunities from coding to technical writing to art, design, and marketing. It's a team effort, but only if there's a team to delegate the efforts to.
And there are other ways to help out. Sign up as a QA tester in our Discord. Make it your mission to share Graphite by word-of-mouth on the forums and online communities you frequent. Put it on the radar of the creators you follow. Create and post your own tutorials on the web. Use it regularly and share your creations in our Discord community and by tagging #Made
Upcoming: FOSDEM '25
If you'll be in Brussels, Belgium for the FOSDEM conference in several weeks (February 1–2), be sure to reach out and arrange a plan to meet up, chat, and pick up some Graphite stickers.
Until next year
Thank you for dedicating the time to read about this latest annual collection of project updates. It has been a privilege leading this community and endeavor since 2021. As we wrap up four years of hard work and venture into the beginnings of a fifth, I am more eager than ever for the adventures that lie in wait during the times ahead.
Happy creating!