npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2026 – Pkg Stats / Ryan Hefner

@graview/render

v0.1.21

Published

The spatial renderer. The DOM path is what ships; the GPU capture path is EXPERIMENTAL — see README.

Downloads

3,278

Readme

@graview/render

The spatial renderer: three planes, an affine transform per plane, and connectors drawn in SVG over the scene.

Two paths, and which one ships

The DOM path is what ships. Each view is an ordinary element with a CSS matrix3d — the same affine transform the GPU path uses, applied by the browser. It is fully interactive, fully accessible, and every claim this project makes about the interface is verified against it.

The GPU capture path is EXPERIMENTAL. It rasterizes each view's DOM subtree with CanvasDrawElement and composites the textures with per-plane blur, which is the part a shader is genuinely better at. It needs Chrome Canary with --enable-blink-features=CanvasDrawElement.

It used to bring the renderer process down on a click. That is fixed. The cause was not the click: a plain hover over a captured view killed it just as reliably, and a keyboard selection of the same node did not. What is fatal is the browser's own hit-test descending into a layoutsubtree canvas child, so on this path the hosts carry pointer-events: none and PointerRouter answers instead — which it had to anyway, because updateElementGeometry does not redirect hit-testing in this build. scripts/verify-capture.mjs holds the claim: the pointer survives, a click still reaches the node that was drawn, and the keyboard still reaches the views.

It stays experimental for a different reason: capture falls off a cliff past ~128 live captures a frame, and every other claim this project makes is verified against the DOM path.

It is published rather than withheld because @graview/react depends on this package for the plane model, the transforms and the frame planner, all of which both paths share. Opting into the capture path is an explicit attachRenderer — nothing reaches it by accident.

What is stable here

  • PLANE_STYLES, styleFor, mixStyles, transformFor — the plane model.
  • planFrame — what to capture, what to draw, where each view lands.
  • PointerRouter, hitTest — hit-testing a click against drawn geometry.

The compositor, the WGSL and the html-in-canvas platform bindings move with the browser feature they are built on.