ScalyPlot is a plotting library focused on making mouse-based data exploration as frictionless as possible. Simultaneously pan, zoom, and scale axes without consciously retargetting your cursor.

• Demo Clip
• Demo Link

Motivation

Plotting libraries or applications are typically designed around customizability for the final output figure's appearance. This often come at the expense of added friction in interactive configuration, where users do not know beforehand what regions of interest they wish to highlight.

The UI may be encumbered with toolbars requiring user selection or hotkeys to switch between panning and zooming (Matplotlib, Gnuplot), or could be buried entirely in menus as axis min/max values (Excel) requiring mental math to convert from the desired adjustments.

This friction can make users reluctant to alter their painstakingly configured view and overlook the data’s finer features, trends being missed due to tunnel vision on a small region, or generally failing to make connections between disjoint sections and their relative context in the big picture.

ScalyPlot lets you freely pan, zoom, and scale axes simultaneously using only the mouse and without needing to focus the cursor on specific targets to do so. The fluidity of simultaneous adjustments removes the cognitive overhead imposed onto researchers that might have prevented them from obtaining a more complete mental picture.

Demo

The Wheel Reinvention Jam 2024 submission is a standalone demo exe: https://codeberg.org/Scaly/Plot/releases

The plotted dataset is currently hardcoded into the executable, mainly for demonstration purposes to showcase the mouse interaction

API

Once implemented, the vision is to be able to use it like this:

const Scaly = @import("ScalyPlot");

const xs, const ys = toSeries(@embedFile("test_run_23-final2 (1)FINAL.txt"));

// interactive window to adjust viewport scaling and position
const view = Scaly.preview(.{ xs, ys }, .{});

const success = view.save("PRL-second-draft-fig2.png", .{});

The goal is to expose two sets of APIs:

• a "simplified" API making it easy for scientists to write throwaway data processing scripts, heavily leveraging comptime options, auto-allocation etc
• an "advanced" API that adheres to idiomatic Zig best-practices (accept custom allocators, allow runtime dynamic options rather than comptime hardcode, etc)

Both API sets should also have a corresponding C ABI available.