GSoC 2026: GPU-Accelerated Brush Engine and integration with Drawing Tablet Input

[timon-schelling]

Synopsis

Graphite currently has no support for drawing tablets or touch input, and its existing brush tool relies on a slow, CPU-based implementation with no awareness of resolution or zoom level. This project introduces drawing tablet and touch device support as first-class input sources, then builds a high-performance, GPU-accelerated brush engine on top, storing strokes in a resolution-independent format inspired by Graphite's non-destructive philosophy and rendering them to texture via WGSL shaders or another approach if research points to a better path. A final phase connects the two by exposing stylus-specific signals such as pressure and tilt as brush parameters, allowing artists to take full advantage of the engine's capabilities through their hardware.

Deliverables

• Upstream winit contributions required to expose drawing tablet and touch events reliably across platforms
• Integration of tablet and touch devices into Graphite's input pipeline, initially treated as high- fidelity pointer input
• A non-destructive stroke data format storing input samples in a resolution-independent representation, compatible with Graphite's node graph architecture
• A GPU-accelerated brush engine implemented most likely as WGSL shaders, though early research may surface alternative or complementary approaches worth taking; built on the shader infrastructure established by the GSoC 2025 GPU raster operations project
• Integration of the new brush engine with Graphite's adaptive resolution system, enabling quality-preserving zoom and resolution changes after strokes are laid down
• Full stylus input bindings: pressure, tilt, and other tablet-specific axes mapped to brush parameters such as size, opacity, and hardness

[timon-schelling]

Week 1

This weeks coding was focused on finishing stuff that was originally planned to be done before GSoC.

Namely the introduction of Resources, a way to store binary data addressable by content hash alongside the node graph. For context #4148 (was merged before GSoC).
The PRs #4168, #4176 and #4187 contain the result of the week.

The resource system was considered a requirement for my GSoC project because without it auto saves stall the editor every second (when raster content is involved) making any kind of drawing nearly impossible.

The following video illustrates that, starting with a graphite version right before the introduction of resources and the second version with my patches applied.

untitled.mp4

A nice side effect is the reduction in file size (before images where stored as raw pixel data inside the graph).

File size reduction for the document in the video from 202.6MB to 18.9MB.

#4165 also embeds fonts as resources allowing documents to render without fetching the fonts from the internet first.

The rest of my time was spend researching for the brush engine and stroke data format. Looking at things like "Ciallo: GPU-Accelerated Rendering of Vector Brush Strokes".

[timon-schelling]

Week 2

This week was spend experimenting with different brush rendering techniques in graphite.
Main focus on Brushes that are rendered with a number of texture stamps.

2026-06-21.17-22-59.mp4

With a very simple WGPU Pipeline backed brush I was already able to get lower latency that the CPU implementation.

2026-06-22.17-41-31.mp4

There was also continued work on systems that are only indirectly related. #4194 #4201 #4225

[timon-schelling]

Week 3

This week was focused on preparing infrastructure that will make it easier/cleaner to implement a lot of GPU Pipelines.

In merge order, all part of the same goal, 3 approaches where tried, final results:

• Add node macro support for injecting nodes into global scope #4221
• Resolve scopes before flattening network #4235
• Extract pipelines from WgpuExecutor into scope-provided pipeline nodes #4210

Combined this allows Pipeline definition to be greatly simplified and locally (before all pipelines lived in the somewhat monolithic WgpuExecutor). The approach now implemented takes advantage of graphenes scope language feature and let me to discovering a compiler bug/missing code path.

Defining a pipeline and using it is now as simple as:

#[node_macro::node(...))]
pub async fn airbrush<'a: 'n>(
	_ctx: impl Ctx,
	#[scope(airbrush_pipeline::IDENTIFIER)] pipeline: WgpuPipelineCache,
	...,
) -> List<Raster<GPU>> {
	let args = AirbrushPipelineArgs { ... };
	pipeline.run::<AirbrushPipeline>(&args).await
}

#[node_macro::node(category(""), inject_scope)]
async fn airbrush_pipeline<'a: 'n>(_ctx: impl Ctx, #[scope(WGPU_EXECUTOR_IDENTIFIER)] executor: &'a WgpuExecutor, #[data] pipeline: WgpuPipelineCache) -> WgpuPipelineCache {
	executor.pipeline_init::<AirbrushPipeline>(pipeline);
	pipeline.clone()
}


pub struct AirbrushPipeline { ... }

pub struct AirbrushPipelineArgs<'a> { ... }

impl AsyncWgpuPipeline for AirbrushPipeline {
	async fn create(...) { ... }
	async fn run(...) { ... }
}

[timon-schelling]

Week 4

In this week I worked on implementing more POC rendering technique implementations for brushes.
Some results that are nice to look at, these are all SDF based and currently take vector as input:

2026-06-23.10-57-58.mp4

2026-06-23.11-41-14.mp4

I also worked on improving build tooling that I was annoyed about for some time #4254 #4256 #4266 .

[timon-schelling]

2026-06-23.14-17-57.mp4