umber 0.3.0__tar.gz → 0.3.2__tar.gz

{umber-0.3.0 → umber-0.3.2}/Cargo.lock

@@ -956,7 +956,7 @@ checksum = "fd3ca314f692efd6c868f8408f53fe444634a845f96c028b97d35f6a1f79f0ee"
 
 [[package]]
 name = "umber-core"
-version = "0.3.0"
+version = "0.3.2"
 dependencies = [
  "criterion",
  "fontdb",
@@ -973,7 +973,7 @@ dependencies = [
 
 [[package]]
 name = "umber-py"
-version = "0.3.0"
+version = "0.3.2"
 dependencies = [
  "pyo3",
  "umber-core",

{umber-0.3.0 → umber-0.3.2}/Cargo.toml

@@ -3,7 +3,7 @@ resolver = "3"
 members = ["crates/umber-core", "crates/umber-py"]
 
 [workspace.package]
-version = "0.3.0"
+version = "0.3.2"
 edition = "2024"
 rust-version = "1.88"
 license = "MIT OR Apache-2.0"

{umber-0.3.0 → umber-0.3.2}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: umber
-Version: 0.3.0
+Version: 0.3.2
 Classifier: Development Status :: 3 - Alpha
 Classifier: Programming Language :: Python :: 3 :: Only
 Classifier: Programming Language :: Python :: 3.12
@@ -32,13 +32,15 @@ Project-URL: Source, https://github.com/TJ-Junhao/umber
 
 # umber
 
+[![Coverage](https://codecov.io/gh/TJ-Junhao/umber/graph/badge.svg)](https://codecov.io/gh/TJ-Junhao/umber)
+
 umber is a plotting library for Python with a rendering core written in Rust. It draws line, step, scatter, area, stacked area, bar, histogram, box, violin, bubble, error bar, band, stem, reference-line, heatmap, mesh, 2-D histogram and hexbin charts on numeric, log, category and time axes, alone or on a grid of panels with shared axes. It has colormaps and colorbars, careful typography, three built-in themes, and PNG or SVG output.
 
 [简体中文](https://github.com/TJ-Junhao/umber/blob/main/README-ZH.md)
 
 ![A line chart of daily temperature at two stations, in the Graphite theme](https://raw.githubusercontent.com/TJ-Junhao/umber/main/assets/readme/lines-graphite.png)
 
-- **Fast on large data.** Rendering runs in Rust: a 1,000,000-point line renders to PNG in about 61 ms, and a 100,000-point scatter in about 49 ms (see [Performance](#performance)).
+- **Fast on large data.** Rendering runs in Rust: a 1,000,000-point line renders to PNG in about 74 ms and a 100,000-point scatter in about 83 ms on a standard GitHub Actions runner, 2.8× and 3.5× faster than matplotlib (see [Performance](#performance)).
 - **Explicit.** Every option is a typed value (`Color`, `Size`, `Dash`, `TickFormat`, …). There are no format strings, no positional style arguments and no silent conversions.
 - **Fails fast, pointing at the problem.** Invalid input raises at the call that caused it, with a message, a hint and the offending argument highlighted in the traceback.
 - **Statically typed.** Category and numeric axes are distinct types: calling `bar` on a numeric axes is reported by pyright and mypy before the code runs.
@@ -147,7 +149,7 @@ Use `fig.axes_at(row=..., col=..., x=..., y=...)` to retrieve axes, including th
 
 ## Colors and colorbars
 
-Heatmaps, meshes, 2-D histograms and hexbins color each cell by its value, and `color=ub.ColorBy(values)` does the same for the points of a scatter or bubble chart. The color-mapped marks of one axes share a single color scale, and a colorbar beside the plot explains it.
+Heatmaps, meshes, 2-D histograms and hexbins color each cell by its value, and `color=ub.ColorBy(values)` does the same for the points of a scatter or bubble chart. The color-mapped marks of one axes share a single color scale, and a colorbar beside the plot explains it. From 10,000 cells, heatmaps, meshes and 2-D histograms draw their cells as one image with one pixel per cell instead of one shape per cell, which keeps large grids small and fast; `render=ub.Render.VECTOR` or `render=ub.Render.RASTER` chooses the form explicitly.
 
 ```python
 import numpy as np
@@ -264,19 +266,25 @@ ax.bar(["a", "b"], [1, 2])  # pyright and mypy: bar() needs Axes[str, float]
 
 ## Performance
 
-Medians from the [criterion](https://github.com/criterion-rs/criterion.rs) suite in `crates/umber-core/benches`, 6 × 4 in at 200 dpi, on an Intel Core Ultra 9 290HX running Linux:
-
-| Case | Time |
-| --- | ---: |
-| 1,000,000-point line → PNG | 61 ms |
-| 1,000,000-point line on a time axis → PNG | 59 ms |
-| 1,000,000-point line → SVG | 20 ms |
-| 100,000-point scatter → PNG | 49 ms |
-| Histogram of 1,000,000 values → PNG | 21 ms |
-| 2-D histogram of 1,000,000 points, 100 × 100 bins → PNG | 15 ms |
-| Hexbin of 1,000,000 points, grid size 50 → PNG | 70 ms |
-| Heatmap of 1,000 × 1,000 cells → PNG | 0.92 s |
-| 4 × 5 grid, one 10,000-point line per panel → PNG | 111 ms |
+End-to-end Python timings next to matplotlib 3.11.2 (Agg backend, default style), from the call that builds the figure to the encoded bytes. Figures are 6 × 4 in, PNG at 200 dpi, with the same input data for both. Each value is the median of 8 runs after a warm-up, with each library in its own process. Measured with umber 0.3.2 on GitHub Actions `ubuntu-latest` (AMD EPYC 9V74, 4 vCPUs, Python 3.12, NumPy 2.5) by the [Python bench workflow](https://github.com/TJ-Junhao/umber/actions/workflows/python-bench.yml) ([this run](https://github.com/TJ-Junhao/umber/actions/runs/39101279625)); the script is `scripts/bench/python_vs_matplotlib.py`. GitHub assigns different CPU models to the same runner label, so absolute times vary between runs; the speed-ups, measured side by side on one machine, are the figures to compare.
+
+| Case | umber | matplotlib | Speed-up |
+| --- | ---: | ---: | ---: |
+| 1,000,000-point line → PNG | 74 ms | 205 ms | 2.8× |
+| 1,000,000-point line on a time axis → PNG | 91 ms | 220 ms | 2.4× |
+| 1,000,000-point line → SVG | 24 ms | 65 ms | 2.7× |
+| 100,000-point scatter → PNG | 83 ms | 291 ms | 3.5× |
+| Histogram of 1,000,000 values → PNG | 32 ms | 64 ms | 2.0× |
+| 2-D histogram of 1,000,000 points, 100 × 100 bins → PNG | 100 ms | 168 ms | 1.7× |
+| Hexbin of 1,000,000 points, grid size 50 → PNG | 127 ms | 141 ms | 1.1× |
+| Heatmap of 1,000 × 1,000 cells → PNG | 194 ms | 252 ms | 1.3× |
+| Heatmap of 1,000 × 1,000 cells → SVG | 175 ms | 443 ms | 2.5× |
+| 4 × 5 grid, one 10,000-point line per panel → PNG | 180 ms | 552 ms | 3.1× |
+| 1,000-point line with a second series, title, labels and legend → PNG | 22 ms | 81 ms | 3.7× |
+| 5-bar chart → PNG | 12 ms | 44 ms | 3.6× |
+| `import` in a fresh interpreter | 66 ms | 310 ms | 4.7× |
+
+Pinned to one CPU, only the scatter plot is notably slower: 125 ms (2.3×). The 4 × 5 grid uses a 12 × 8 in figure. The script's docstring lists where the two libraries do different work, for example the hexbin grids, which are built differently.
 
 Lines with sorted numeric or time x values are downsampled when they have more than four points per pixel column of the plot (counted at a nominal 300 dpi), keeping the first, last, minimum and maximum point in each column, which is visually lossless. Large scatter plots are composited on up to 8 threads; the output is the same for any number of threads.
 

{umber-0.3.0 → umber-0.3.2}/README-ZH.md

@@ -1,12 +1,14 @@
 # umber
 
+[![测试覆盖率](https://codecov.io/gh/TJ-Junhao/umber/graph/badge.svg)](https://codecov.io/gh/TJ-Junhao/umber)
+
 umber 是一个 Python 绘图库，渲染核心用 Rust 编写。它可以绘制折线图、阶梯图、散点图、面积图、堆叠面积图、柱状图、直方图、箱线图、小提琴图、气泡图、误差棒、区间带、杆状图、参考线、热力图、网格色块图（mesh）、二维直方图和六边形分箱图（hexbin），支持数值轴、对数轴、类别轴和时间轴，可以单独成图，也可以排成共享坐标轴的多面板网格。它提供 colormap 和 colorbar，排版考究，内置三套主题，输出 PNG 或 SVG。
 
 [English](https://github.com/TJ-Junhao/umber/blob/main/README.md)
 
 ![Graphite 主题下两个站点的每日气温折线图](https://raw.githubusercontent.com/TJ-Junhao/umber/main/assets/readme/lines-graphite.png)
 
-- **大数据量也快。** 渲染在 Rust 中完成：100 万个点的折线渲染成 PNG 约 61 ms，10 万个点的散点图约 49 ms（见[性能](#性能)）。
+- **大数据量也快。** 渲染在 Rust 中完成：在标准的 GitHub Actions runner 上，100 万个点的折线渲染成 PNG 约 74 ms，10 万个点的散点图约 83 ms，分别比 matplotlib 快 2.8× 和 3.5×（见[性能](#性能)）。
 - **显式。** 每个选项都是有类型的值（`Color`、`Size`、`Dash`、`TickFormat` 等）。没有格式字符串，没有位置式的样式参数，也没有隐式转换。
 - **尽早报错，并指出问题所在。** 非法输入在引发它的那次调用处就报错，附带说明、提示，并在 traceback 中高亮出错的参数。
 - **静态类型。** 类别轴和数值轴是不同的类型：在数值轴上调用 `bar`，pyright 和 mypy 在运行前就会报错。
@@ -115,7 +117,7 @@ variant.axes_at(row=0, col=1).title("Comparison")  # 原图不变
 
 ## 颜色与 colorbar
 
-热力图、网格色块图、二维直方图和六边形分箱图按数值为每个格子着色；`color=ub.ColorBy(values)` 对散点图或气泡图的点做同样的事。同一个 axes 上所有按值着色的 mark 共用一个 color scale，plot 旁的 colorbar 说明这一映射。
+热力图、网格色块图、二维直方图和六边形分箱图按数值为每个格子着色；`color=ub.ColorBy(values)` 对散点图或气泡图的点做同样的事。同一个 axes 上所有按值着色的 mark 共用一个 color scale，plot 旁的 colorbar 说明这一映射。热力图、网格色块图和二维直方图从 10,000 个格子起把格子画成一张每格一个像素的图像，而不是每格一个形状，使大网格的文件更小、渲染更快；`render=ub.Render.VECTOR` 或 `render=ub.Render.RASTER` 可显式指定画法。
 
 ```python
 import numpy as np
@@ -232,19 +234,25 @@ ax.bar(["a", "b"], [1, 2])  # pyright 和 mypy 报错：bar() 需要 Axes[str, f
 
 ## 性能
 
-以下是 `crates/umber-core/benches` 中 [criterion](https://github.com/criterion-rs/criterion.rs) 测试套件的中位数，图幅 6 × 4 英寸、200 dpi，运行于 Linux 下的 Intel Core Ultra 9 290HX：
-
-| 场景 | 耗时 |
-| --- | ---: |
-| 100 万点折线 → PNG | 61 ms |
-| 时间轴上的 100 万点折线 → PNG | 59 ms |
-| 100 万点折线 → SVG | 20 ms |
-| 10 万点散点图 → PNG | 49 ms |
-| 100 万个值的直方图 → PNG | 21 ms |
-| 100 万个点的二维直方图，100 × 100 个 bin → PNG | 15 ms |
-| 100 万个点的六边形分箱图，grid size 50 → PNG | 70 ms |
-| 1,000 × 1,000 个格子的热力图 → PNG | 0.92 s |
-| 4 × 5 网格，每格一条 1 万个点的折线 → PNG | 111 ms |
+以下是与 matplotlib 3.11.2（Agg 后端、默认样式）对比的 Python 端到端耗时，从构建图形的调用开始，到得到编码后的字节为止。图幅 6 × 4 英寸，PNG 为 200 dpi，两者使用相同的输入数据。每个数值是预热一次后 8 次运行的中位数，两个库各在独立的进程中运行。测量环境为 umber 0.3.2，GitHub Actions `ubuntu-latest`（AMD EPYC 9V74，4 个 vCPU，Python 3.12，NumPy 2.5），由 [Python bench workflow](https://github.com/TJ-Junhao/umber/actions/workflows/python-bench.yml) 运行（[本次运行](https://github.com/TJ-Junhao/umber/actions/runs/39101279625)）；脚本为 `scripts/bench/python_vs_matplotlib.py`。同一个 runner 标签每次可能分到不同型号的 CPU，所以绝对耗时会随运行变化；在同一台机器上交替测得的加速比才是可比较的数字。
+
+| 场景 | umber | matplotlib | 加速比 |
+| --- | ---: | ---: | ---: |
+| 100 万点折线 → PNG | 74 ms | 205 ms | 2.8× |
+| 时间轴上的 100 万点折线 → PNG | 91 ms | 220 ms | 2.4× |
+| 100 万点折线 → SVG | 24 ms | 65 ms | 2.7× |
+| 10 万点散点图 → PNG | 83 ms | 291 ms | 3.5× |
+| 100 万个值的直方图 → PNG | 32 ms | 64 ms | 2.0× |
+| 100 万个点的二维直方图，100 × 100 个 bin → PNG | 100 ms | 168 ms | 1.7× |
+| 100 万个点的六边形分箱图，grid size 50 → PNG | 127 ms | 141 ms | 1.1× |
+| 1,000 × 1,000 个格子的热力图 → PNG | 194 ms | 252 ms | 1.3× |
+| 1,000 × 1,000 个格子的热力图 → SVG | 175 ms | 443 ms | 2.5× |
+| 4 × 5 网格，每格一条 1 万个点的折线 → PNG | 180 ms | 552 ms | 3.1× |
+| 1,000 个点的折线加第二条序列、标题、坐标轴标签和图例 → PNG | 22 ms | 81 ms | 3.7× |
+| 5 根柱子的柱状图 → PNG | 12 ms | 44 ms | 3.6× |
+| 在新解释器中 `import` | 66 ms | 310 ms | 4.7× |
+
+绑定到单个 CPU 时，只有散点图明显变慢：125 ms（2.3×）。4 × 5 网格使用 12 × 8 英寸的图幅。两个库在哪些场景下做的工作不同（例如六边形分箱的网格构建方式不同），见脚本的 docstring。
 
 对于 x 值有序的数值或时间折线，按 300 dpi 的标称分辨率计算绘图区的像素列数，点数超过列数的四倍时按列降采样，保留每列的首点、末点、最小值和最大值，视觉上无损。大型散点图最多使用 8 个线程合成；无论用几个线程，输出都完全相同。
 

{umber-0.3.0 → umber-0.3.2}/README.md

@@ -1,12 +1,14 @@
 # umber
 
+[![Coverage](https://codecov.io/gh/TJ-Junhao/umber/graph/badge.svg)](https://codecov.io/gh/TJ-Junhao/umber)
+
 umber is a plotting library for Python with a rendering core written in Rust. It draws line, step, scatter, area, stacked area, bar, histogram, box, violin, bubble, error bar, band, stem, reference-line, heatmap, mesh, 2-D histogram and hexbin charts on numeric, log, category and time axes, alone or on a grid of panels with shared axes. It has colormaps and colorbars, careful typography, three built-in themes, and PNG or SVG output.
 
 [简体中文](https://github.com/TJ-Junhao/umber/blob/main/README-ZH.md)
 
 ![A line chart of daily temperature at two stations, in the Graphite theme](https://raw.githubusercontent.com/TJ-Junhao/umber/main/assets/readme/lines-graphite.png)
 
-- **Fast on large data.** Rendering runs in Rust: a 1,000,000-point line renders to PNG in about 61 ms, and a 100,000-point scatter in about 49 ms (see [Performance](#performance)).
+- **Fast on large data.** Rendering runs in Rust: a 1,000,000-point line renders to PNG in about 74 ms and a 100,000-point scatter in about 83 ms on a standard GitHub Actions runner, 2.8× and 3.5× faster than matplotlib (see [Performance](#performance)).
 - **Explicit.** Every option is a typed value (`Color`, `Size`, `Dash`, `TickFormat`, …). There are no format strings, no positional style arguments and no silent conversions.
 - **Fails fast, pointing at the problem.** Invalid input raises at the call that caused it, with a message, a hint and the offending argument highlighted in the traceback.
 - **Statically typed.** Category and numeric axes are distinct types: calling `bar` on a numeric axes is reported by pyright and mypy before the code runs.
@@ -115,7 +117,7 @@ Use `fig.axes_at(row=..., col=..., x=..., y=...)` to retrieve axes, including th
 
 ## Colors and colorbars
 
-Heatmaps, meshes, 2-D histograms and hexbins color each cell by its value, and `color=ub.ColorBy(values)` does the same for the points of a scatter or bubble chart. The color-mapped marks of one axes share a single color scale, and a colorbar beside the plot explains it.
+Heatmaps, meshes, 2-D histograms and hexbins color each cell by its value, and `color=ub.ColorBy(values)` does the same for the points of a scatter or bubble chart. The color-mapped marks of one axes share a single color scale, and a colorbar beside the plot explains it. From 10,000 cells, heatmaps, meshes and 2-D histograms draw their cells as one image with one pixel per cell instead of one shape per cell, which keeps large grids small and fast; `render=ub.Render.VECTOR` or `render=ub.Render.RASTER` chooses the form explicitly.
 
 ```python
 import numpy as np
@@ -232,19 +234,25 @@ ax.bar(["a", "b"], [1, 2])  # pyright and mypy: bar() needs Axes[str, float]
 
 ## Performance
 
-Medians from the [criterion](https://github.com/criterion-rs/criterion.rs) suite in `crates/umber-core/benches`, 6 × 4 in at 200 dpi, on an Intel Core Ultra 9 290HX running Linux:
-
-| Case | Time |
-| --- | ---: |
-| 1,000,000-point line → PNG | 61 ms |
-| 1,000,000-point line on a time axis → PNG | 59 ms |
-| 1,000,000-point line → SVG | 20 ms |
-| 100,000-point scatter → PNG | 49 ms |
-| Histogram of 1,000,000 values → PNG | 21 ms |
-| 2-D histogram of 1,000,000 points, 100 × 100 bins → PNG | 15 ms |
-| Hexbin of 1,000,000 points, grid size 50 → PNG | 70 ms |
-| Heatmap of 1,000 × 1,000 cells → PNG | 0.92 s |
-| 4 × 5 grid, one 10,000-point line per panel → PNG | 111 ms |
+End-to-end Python timings next to matplotlib 3.11.2 (Agg backend, default style), from the call that builds the figure to the encoded bytes. Figures are 6 × 4 in, PNG at 200 dpi, with the same input data for both. Each value is the median of 8 runs after a warm-up, with each library in its own process. Measured with umber 0.3.2 on GitHub Actions `ubuntu-latest` (AMD EPYC 9V74, 4 vCPUs, Python 3.12, NumPy 2.5) by the [Python bench workflow](https://github.com/TJ-Junhao/umber/actions/workflows/python-bench.yml) ([this run](https://github.com/TJ-Junhao/umber/actions/runs/39101279625)); the script is `scripts/bench/python_vs_matplotlib.py`. GitHub assigns different CPU models to the same runner label, so absolute times vary between runs; the speed-ups, measured side by side on one machine, are the figures to compare.
+
+| Case | umber | matplotlib | Speed-up |
+| --- | ---: | ---: | ---: |
+| 1,000,000-point line → PNG | 74 ms | 205 ms | 2.8× |
+| 1,000,000-point line on a time axis → PNG | 91 ms | 220 ms | 2.4× |
+| 1,000,000-point line → SVG | 24 ms | 65 ms | 2.7× |
+| 100,000-point scatter → PNG | 83 ms | 291 ms | 3.5× |
+| Histogram of 1,000,000 values → PNG | 32 ms | 64 ms | 2.0× |
+| 2-D histogram of 1,000,000 points, 100 × 100 bins → PNG | 100 ms | 168 ms | 1.7× |
+| Hexbin of 1,000,000 points, grid size 50 → PNG | 127 ms | 141 ms | 1.1× |
+| Heatmap of 1,000 × 1,000 cells → PNG | 194 ms | 252 ms | 1.3× |
+| Heatmap of 1,000 × 1,000 cells → SVG | 175 ms | 443 ms | 2.5× |
+| 4 × 5 grid, one 10,000-point line per panel → PNG | 180 ms | 552 ms | 3.1× |
+| 1,000-point line with a second series, title, labels and legend → PNG | 22 ms | 81 ms | 3.7× |
+| 5-bar chart → PNG | 12 ms | 44 ms | 3.6× |
+| `import` in a fresh interpreter | 66 ms | 310 ms | 4.7× |
+
+Pinned to one CPU, only the scatter plot is notably slower: 125 ms (2.3×). The 4 × 5 grid uses a 12 × 8 in figure. The script's docstring lists where the two libraries do different work, for example the hexbin grids, which are built differently.
 
 Lines with sorted numeric or time x values are downsampled when they have more than four points per pixel column of the plot (counted at a nominal 300 dpi), keeping the first, last, minimum and maximum point in each column, which is visually lossless. Large scatter plots are composited on up to 8 threads; the output is the same for any number of threads.
 

{umber-0.3.0 → umber-0.3.2}/THIRD-PARTY-LICENSES.txt

@@ -592,7 +592,7 @@ MIT License
 ================================================================================
 
 Used by:
-  - umber-core 0.3.0
+  - umber-core 0.3.2
 
 MIT License
 
@@ -622,7 +622,7 @@ MIT License
 ================================================================================
 
 Used by:
-  - umber-py 0.3.0
+  - umber-py 0.3.2
 
 MIT License
 

{umber-0.3.0 → umber-0.3.2}/crates/umber-core/src/category_label_tests.rs

@@ -245,6 +245,7 @@ fn smallest_self_fitting_step(
                     &candidate,
                     grid.span(input.axes.cells()),
                     [true, true],
+                    &layout::LabelCache::new(lib),
                 );
                 if let Ok(solution) = layout::solve_grid(grid, &[bands])
                     && Side::X

{umber-0.3.0 → umber-0.3.2}/crates/umber-core/src/coverage.rs

@@ -3,7 +3,8 @@
 //! Points and segments are counted once. Filled paths are measured in square points by
 //! horizontal scanlines at most one point apart, with the path's own winding rule. This also
 //! handles overlapping contours and areas that cross themselves, rather than cancelling their
-//! signed areas. Curves in rounded bar corners are flattened before scoring.
+//! signed areas. Curves in rounded bar corners are flattened before scoring. Images count the
+//! exact area of their pixels that are not transparent.
 
 use crate::layout::{Area, Frame};
 use crate::{FillRule, Item, Paint, Path, PathVerb, Point};
@@ -18,12 +19,60 @@ struct Filled {
     rule: FillRule,
 }
 
+/// The pixels of one image that are not transparent, each a rectangle of its share of the
+/// image's rectangle.
+#[derive(Debug, Clone, PartialEq)]
+struct Pixels {
+    /// The left, top, right and bottom edges of the image.
+    bounds: [f64; 4],
+    /// The number of pixel columns.
+    width: usize,
+    /// Whether each pixel, row by row from the top, is drawn (not transparent).
+    drawn: Vec<bool>,
+}
+
+impl Pixels {
+    /// The area of the drawn pixels inside `box_`, in square points.
+    fn overlap(&self, box_: &Frame) -> f64 {
+        let [left, top, right, bottom] = self.bounds;
+        let height = self.drawn.len() / self.width.max(1);
+        // The overlap of each column with the box along x, and of each row along y.
+        let lengths = |start: f64, end: f64, count: usize, lo: f64, hi: f64| -> Vec<f64> {
+            let size = (end - start) / count as f64;
+            (0..count)
+                .map(|i| {
+                    let (a, b) = (start + size * i as f64, start + size * (i + 1) as f64);
+                    (b.min(hi) - a.max(lo)).max(0.0)
+                })
+                .collect()
+        };
+        let columns = lengths(left, right, self.width, box_.x, box_.right());
+        let rows = lengths(top, bottom, height, box_.y, box_.bottom());
+        let mut area = 0.0;
+        for (row, &along_y) in rows.iter().enumerate() {
+            if along_y == 0.0 {
+                continue;
+            }
+            let drawn = &self.drawn[row * self.width..(row + 1) * self.width];
+            let along_x: f64 = columns
+                .iter()
+                .zip(drawn)
+                .filter(|&(_, &d)| d)
+                .map(|(&x, _)| x)
+                .sum();
+            area += along_x * along_y;
+        }
+        area
+    }
+}
+
 /// Geometry after axis mapping, clipping and downsampling, in drawing order within each kind.
 #[derive(Debug, Clone, Default, PartialEq)]
 pub(crate) struct Geometry {
     points: Vec<XY>,
     segments: Vec<[XY; 2]>,
     fills: Vec<Filled>,
+    images: Vec<Pixels>,
 }
 
 fn xy(p: Point) -> XY {
@@ -83,6 +132,21 @@ impl Geometry {
                     });
                 }
             }
+            Item::Image {
+                rect,
+                width,
+                height,
+                pixels,
+            } => {
+                if *width > 0 && pixels.len() == (*width as usize) * (*height as usize) {
+                    let (x, y) = (f64::from(rect.x), f64::from(rect.y));
+                    self.images.push(Pixels {
+                        bounds: [x, y, x + f64::from(rect.width), y + f64::from(rect.height)],
+                        width: *width as usize,
+                        drawn: pixels.iter().map(|c| c.a > 0).collect(),
+                    });
+                }
+            }
             Item::Text(_) => {}
         }
     }
@@ -108,9 +172,12 @@ impl Geometry {
             .iter()
             .filter(|s| crosses(**s, &bounds))
             .count() as f64;
-        self.fills.iter().fold(points + segments, |score, fill| {
+        let fills = self.fills.iter().fold(points + segments, |score, fill| {
             score + fill.overlap(&bounds)
-        })
+        });
+        self.images
+            .iter()
+            .fold(fills, |score, image| score + image.overlap(&bounds))
     }
 }
 
@@ -612,6 +679,7 @@ mod tests {
             points: vec![[50.0, 50.0], [10.0, 10.0]],
             segments: vec![[[0.0, 50.0], [100.0, 50.0]], [[0.0, 0.0], [10.0, 10.0]]],
             fills: Vec::new(),
+            images: Vec::new(),
         };
         assert_eq!(geometry.coverage(&area, &box_), 2.0);
     }

{umber-0.3.0 → umber-0.3.2}/crates/umber-core/src/draw/cells.rs

@@ -9,9 +9,73 @@
 //! edges of its grid or into an empty cell, so every edge that faces the background stays
 //! exactly where it is. Where a cell reaches both right and down but the cell diagonally below
 //! it to the right is empty, the corner where the two reaches meet is cut out of it.
+//!
+//! A grid drawn as one image instead ([`Render`](crate::Render)) needs none of this: its cells
+//! are the pixels of one [`Item::Image`], with transparent pixels for empty cells, and the
+//! renderers meet them without seams.
 
 use super::mapping::point;
+use crate::Rgba;
 use crate::geometry::Path;
+use crate::scene::{Item, Rect};
+
+/// A transparent pixel: an empty cell of an image.
+pub(super) const CLEAR: Rgba = Rgba {
+    r: 0,
+    g: 0,
+    b: 0,
+    a: 0,
+};
+
+/// How far, in points, the image of a grid may reach past the part of it that is shown. Cells
+/// cut by explicit limits are drawn whole and clipped, so an image reaches past the limits by
+/// at most one cell; a cell wider than this, which only limits inside a few cells give, is too
+/// wide to place exactly in the scene's precision: [`Render::Auto`](crate::Render::Auto) draws
+/// such a grid as vector shapes, and [`Render::Raster`](crate::Render::Raster) fails.
+pub(super) const MAX_IMAGE_REACH: f64 = 10_000.0;
+
+/// How far, in points, an edge of a grid drawn as one image may lie from its place among the
+/// image's evenly spaced pixels, on the final plot.
+pub(super) const MAX_EDGE_OFFSET: f64 = 0.001;
+
+/// The grid of `width` by `height` cells whose colors are `pixels` (row by row from the top,
+/// [`CLEAR`] for an empty cell) as one image over `bounds`, the left, top, right and bottom
+/// edges of its outer cells in plot points. When explicit limits cut its outer cells, `visible`
+/// is the part of `bounds` shown, and the image is clipped to it; otherwise `visible` equals
+/// `bounds`. `None` when every cell is empty.
+pub(super) fn image_item(
+    bounds: [f64; 4],
+    visible: [f64; 4],
+    (width, height): (usize, usize),
+    pixels: Vec<Rgba>,
+) -> Option<Item> {
+    if pixels.iter().all(|c| c.a == 0) {
+        return None;
+    }
+    let rect = |[left, top, right, bottom]: [f64; 4]| {
+        let (x0, x1) = (left.min(right), left.max(right));
+        let (y0, y1) = (top.min(bottom), top.max(bottom));
+        Rect {
+            x: x0 as f32,
+            y: y0 as f32,
+            width: (x1 - x0) as f32,
+            height: (y1 - y0) as f32,
+        }
+    };
+    let image = Item::Image {
+        rect: rect(bounds),
+        width: u32::try_from(width).ok()?,
+        height: u32::try_from(height).ok()?,
+        pixels,
+    };
+    if visible == bounds {
+        return Some(image);
+    }
+    Some(Item::Group {
+        clip: Some(rect(visible)),
+        items: vec![image],
+    })
+}
 
 /// How far, in points, a cell reaches under a neighbour drawn after it; at most half the
 /// neighbour's size along that axis.

{umber-0.3.0 → umber-0.3.2}/crates/umber-core/src/draw/heatmap.rs

@@ -6,9 +6,13 @@
 //! cell reaches under its drawn neighbours to the right and below. A cell ends exactly at its
 //! bands where it has no drawn neighbour: at the heatmap's right and bottom edges, and next to
 //! an empty cell.
+//!
+//! Drawn as one image ([`Render`](crate::Render)), a heatmap is one pixel per pair of category
+//! bands from its first to its last category on each axis, over exactly those bands: a band of
+//! another heatmap's category between them, and an empty cell, is a transparent pixel.
 
 use super::MarkContext;
-use super::cells::{Reach, cell_path, reach};
+use super::cells::{CLEAR, Reach, cell_path, image_item, reach};
 use super::chrome::text;
 use super::mapping::AxisMaps;
 use crate::color_scale::ResolvedColorScale;
@@ -137,8 +141,56 @@ fn mark_indices(axis: &CategoryScale, names: &[String]) -> Vec<Option<usize>> {
     indices
 }
 
-/// The cells of `mark` as opaque fills, appended to `items`; nothing without a color scale
-/// (no finite value on the axes).
+/// The cells of `mark` as one image, one pixel per pair of category bands from its first to
+/// its last x and y category on the axes, over those bands (see the module documentation);
+/// `None` when no cell is drawn or either axis is not a category axis, which the model rules
+/// out.
+fn image(
+    maps: AxisMaps,
+    resolved: &Resolved,
+    mark: &HeatmapMark,
+    scale: &ResolvedColorScale,
+) -> Option<Item> {
+    let (AxisScale::Category(columns), AxisScale::Category(rows)) =
+        (&resolved.x.scale, &resolved.y.scale)
+    else {
+        return None;
+    };
+    let column_at = mark_indices(columns, mark.x_categories());
+    let row_at = mark_indices(rows, mark.y_categories());
+    let span = |indices: &[Option<usize>]| {
+        let first = indices.iter().position(Option::is_some)?;
+        let end = indices.iter().rposition(Option::is_some)? + 1;
+        Some(first..end)
+    };
+    let (x_span, y_span) = (span(&column_at)?, span(&row_at)?);
+    let width = mark.x_categories().len();
+    let color = |row: Option<usize>, column: Option<usize>| {
+        let value = *mark.values().get(row? * width + column?)?;
+        scale.color(value)
+    };
+    let pixels: Vec<Rgba> = row_at[y_span.clone()]
+        .iter()
+        .flat_map(|&row| {
+            column_at[x_span.clone()]
+                .iter()
+                .map(move |&column| color(row, column).unwrap_or(CLEAR))
+        })
+        .collect();
+    let (left, top) = (columns.band(x_span.start).0, rows.band(y_span.start).0);
+    let (right, bottom) = (columns.band(x_span.end - 1).1, rows.band(y_span.end - 1).1);
+    let bounds = [
+        maps.x.plot_at(left),
+        maps.y.plot_at(top),
+        maps.x.plot_at(right),
+        maps.y.plot_at(bottom),
+    ];
+    image_item(bounds, bounds, (x_span.len(), y_span.len()), pixels)
+}
+
+/// The cells of `mark` appended to `items`: as one image when its options draw it as one
+/// ([`Render`](crate::Render)), else as opaque fills; nothing without a color scale (no finite
+/// value on the axes).
 pub(super) fn heatmap_items(
     context: &MarkContext<'_>,
     resolved: &Resolved,
@@ -148,6 +200,14 @@ pub(super) fn heatmap_items(
     let Some(scale) = &resolved.color else {
         return;
     };
+    let count = mark
+        .x_categories()
+        .len()
+        .saturating_mul(mark.y_categories().len());
+    if mark.options().render.draws_image(count, true) {
+        items.extend(image(context.maps, resolved, mark, scale));
+        return;
+    }
     items.extend(
         cells(context.maps, resolved, mark, scale)
             .iter()