G draws one scene graph through Canvas2D, SVG, WebGL, WebGPU or CanvasKit

One scene, five backends, and a switch at runtime

G is described as the underlying rendering engine of AntV, and its job is to give upper layer products consistent 2D and 3D drawing regardless of the graphics API underneath. The project adapts Canvas2D, SVG, WebGL, WebGPU, CanvasKit and Node.js on the web side, and the documentation makes the switching explicit: the rendering environments are supported and can be switched at runtime, with server-side rendering as well. That is the architectural bet of the whole project. A visualisation library that binds you to one backend inherits that backend's limits, and an application that has to survive a CanvasKit port, an SVG export for print, or a server-rendered snapshot has to rewrite its drawing code for each. G puts the backend behind a plugin boundary so that the scene graph stays the same. The cost is that not every capability is available in every backend, which is the thread running through the rest of this project.

A DOM-shaped API so D3 and Hammer.js code survives the port

The API design is where G tries to remove the usual migration tax. The graphics and event system is compatible with the DOM Element and Event API, and the animation system is compatible with the Web Animations API. The stated purpose is adaptation to the existing web ecosystem, naming D3 and the Hammer.js gesture library as examples, at what the documentation calls a very low cost. The practical meaning is that a great deal of existing front-end code, which manipulates elements, listens for events, or schedules animations, can be pointed at G objects rather than DOM nodes, and existing libraries that expect a DOM-like interface have a chance of working unchanged. This is the reason to pick a rendering engine over a thin wrapper on Canvas2D: the abstraction is not only the drawing commands, it is the object model and the event system around them.

Picking is a plugin, and it comes in two flavours

Mouse and touch interaction with drawn objects is not built into the core. It arrives through a picking plugin, and the plugin list shows two implementations with different underlying mechanics. canvas-picker does picking with Canvas2D and mathematical calculations, and svg-picker does picking with SVG and the DOM API. That pairing is the shape of the whole plugin system: for each capability there is a rendering related plugin, a picking plugin, and sometimes more. Interaction itself is handled by dom-interaction, which binds event listeners with the DOM API, and by g-plugin-dragndrop, which provides drag and drop based on PointerEvents. For 3D scenes, g-plugin-control provides camera interaction. The choice of a renderer decides which picker you install, and the choice of a picker decides which event approach you write against, so the backend decision propagates further than the drawing code.

Physics, layout, rough styles and accessibility are separate installs

Everything beyond raw drawing arrives as a plugin, and the breadth is the point of the project. Physics comes in three flavours, g-plugin-box2d based on Box2D, g-plugin-matterjs based on matter.js, and g-plugin-physx based on PhysX, so a scene can be simulated in a browser, in a test, or with a native engine. Layout is g-plugin-yoga, which provides flex layout capabilities based on Yoga. Styling is g-plugin-rough-canvas-renderer and g-plugin-rough-svg-renderer, which render with rough.js for a hand-drawn look. Accessibility is g-plugin-a11y. Search in the scene graph is g-plugin-css-select, which supports retrieval using CSS selectors, which is a small feature that reveals a lot about the design, since the scene graph is treated as a queryable document rather than a flat list of draw calls. Every one of these is a separate dependency with its own version and its own compatibility story with your chosen backend.

GPGPU for graph algorithms on WebGPU

One capability stands apart from the 2D scene work: GPGPU. The g-plugin-gpgpu plugin provides GPGPU capabilities based on WebGPU, and the project points to webgpu-graph as a library of graph analysis algorithms using GPU acceleration. The description says the engine provides GPGPU support for algorithms suitable for parallel computing in graph scenarios, and a separate item mentions high performance rendering and computing with WebGPU-based GPGPU support for parallelizable algorithms. The demo folder makes the intent clear, with dedicated pages such as demo/gpgpu.html and demo/3d.html, and 3D examples in the documentation for a force directed graph and for geometry. If your workload is large-graph analysis, this is the part of G that is hard to replicate with an ordinary canvas wrapper, and the part that will dictate your backend choice, since WebGPU availability becomes a hard requirement rather than a preference.

The repository is a pnpm monorepo with its own release pipeline

The source tree is a workspace, not a single package. The root package.json is marked private and drives the whole repo with pnpm across packages/, with scripts separated into dev, build, test, code quality and release groups. The pieces you can run locally are these:

npm run dev
npm run test:unit
npm run test:visual
npm run benchmark

The dev script starts vite, the two test scripts run jest against separate configs, jest.unit.config.js and jest.visual.config.js, and the benchmark script runs the benchmark directory. The release process is changeset based, with npm run changeset, npm run version and npm run release publishing with the latest tag, and the repo also carries husky hooks, eslint and prettier configuration, and a commitlint config. Two observations for a team evaluating this. First, the visual test suite implies that the project treats rendered output as something to assert on, which matters for a renderer where small differences are easy to introduce. Second, publishing happens per package rather than for the repository as a whole, so your upgrade surface is the set of @antv packages you actually depend on.

Two packages, two release tracks, and an MIT licence

The published surface splits into at least two lines. @antv/g was released as 6.3.0 on 2025-12-22, and @antv/g-lite moved to 2.7.1 on 2026-10-10, with an earlier 2.5.0 on 2025-10-13, and the last push to the repository was on 2026-10-16. The lite line is clearly the one receiving recent work, and the name suggests a reduced core. The licence is MIT, declared in the root package.json and shown as a badge in the README, which is permissive enough for commercial embedding including the case of a chart library shipped inside a closed-source product. The open question for an adopter is the one any monorepo with several published packages raises: which of the packages do you actually take, and how many of them move independently of each other.

Where the abstraction costs more than it saves

There are two clear reasons to skip G. The first is that the plugin model pushes every capability out of the core, so a feature you need may exist as a plugin for a backend you are not using, and the fallback is writing it yourself against the raw API. The second is the version surface. A single visual application that needs rendering, picking, drag and drop, a physics engine, layout and accessibility is depending on at least six packages, each with its own release timing, and the semver ranges you hold in your lockfile become the actual contract. The alternative approach is to bind directly to one rendering API and accept that the code is tied to it. That alternative is cheaper when there is one target environment and one set of features, and it is the better trade whenever the feature list is stable and the backend is not going to change. G earns its cost when the environment genuinely varies, which is exactly the case its own documentation claims for the AntV product family.

Editorial conclusion

G earns its place when a visualisation product has to run on more than one rendering backend, or when graph algorithms need the WebGPU GPGPU path, and it earns it slowly otherwise, because the convenience of switching environments is paid for in plugin wiring, in an abstraction layer above raw graphics calls, and in a monorepo release process you do not control. Before adopting it, check which of the capabilities you actually need exist as plugins for the backend you plan to ship, since picking, physics, layout, accessibility and GPGPU are all separate installs, and read the release history for the package you depend on, because @antv/g and @antv/g-lite are versioned and released on their own schedules.

Frequently asked questions

Official sources

1. antvis/G on GitHub
2. Issues
3. Project website
4. README
5. Releases