[Bug]: snapshot accessibility decodes PNGs again just to read their dimensions#19220

opened25d agobyAAksharP5

With snapshot accessibility enabled, the desktop process decodes the captured PNG again solely to read its width and height. On Linux x64 with Electron 44.4.5, this adds roughly 4–10 ms of synchronous work per capture in the cases measured below.

The capture backends already validate or encode the PNG. The additional decode happens in snapShotImageSize, before starting the accessibility read. The existing readImageDimensions helper can read those dimensions from the header.

Reproduction and measurements

At upstream dff750b1b8, compare the original function with the same function using the shared header reader, in an Electron main process. Use valid PNGs and enable accessibility when exercising the capture path.

Measured with Electron 44.4.5, its bundled Node 24.21.0, Linux 7.2.8 x64, Intel Core i5-14400F. Inputs were synthetic editor-pattern RGBA PNGs, with no private screenshots. Each decode measurement is the median of 15 calls after three warmups; header calls were batched. The original and replacement returned identical pixel dimensions.

PNG	Encoded bytes	Original dimension lookup	Header lookup
1440 × 900	345,095	3.77 ms	<0.001 ms
2560 × 1600	1,029,370	10.45 ms	<0.001 ms

This isolates the dimension lookup. It does not measure total capture latency or idle CPU usage. The system Node used for development is 26.11.1; the native benchmark and an additional focused test run used Electron's Node 24.21.0.

A small reproduction of the redundant decode cost, run as an Electron main-process script without opening a window:

1	const { nativeImage } = require("electron");
2	const { performance } = require("node:perf_hooks");
3	const width = 2560, height = 1600;
4	const pixels = Buffer.alloc(width * height * 4);
5	for (let y = 0; y < height; y++) {
6	for (let x = 0; x < width; x++) {
7	const offset = (y * width + x) * 4;
8	const ink = y % 22 < 12 && x % 13 < 8 && (x * 17 + y * 23) % 101 < 60;
9	const value = ink ? (x * 13 + y * 7) % 120 + 110 : (Math.floor(x / 240) + Math.floor(y / 180)) % 3 * 8 + 22;
10	pixels[offset] = value;
11	pixels[offset + 1] = value + 3;
12	pixels[offset + 2] = value + 8;
13	pixels[offset + 3] = 255;
14	}
15	}
16	const png = nativeImage.createFromBitmap(pixels, { width, height }).toPNG();
17	for (let i = 0; i < 3; i++) nativeImage.createFromBuffer(png).getSize();
18	const samples = [];
19	for (let i = 0; i < 15; i++) {
20	const start = performance.now();
21	const size = nativeImage.createFromBuffer(png).getSize();
22	samples.push(performance.now() - start);
23	if (size.width !== png.readUInt32BE(16) \|\| size.height !== png.readUInt32BE(20)) {
24	throw new Error("dimension mismatch");
25	}
26	}
27	console.log({ bytes: png.length, medianMs: samples.sort((a, b) => a - b)[7] });
28	process.exit(0);

The encoded size can differ with Electron's encoder. The measured table used zlib-generated PNGs and the actual original/replacement function bodies.

Expected behavior and scope

Read dimensions from the already validated PNG without another pixel decode. Preserve the current logical-bounds fallback when dimensions are unavailable. No capture settings, image bytes, accessibility coordinates, or user workflow need to change.

Searches of issues, PRs, discussions, and the existing performance tracker found no matching report. The browser-viewport sizing work in #16728 and unchanged-PiP encoding work in #19193 concern separate paths.

Investigated with GPT-6.1-Sol in Codex. Independently reviewed by GPT-6-Astra at high reasoning effort before submission.

JJulius Marminge17d ago

On 70e5e384da, the reporter’s synthetic PNG benchmark runs in Electron 44.4.5 / Node 24.21.0 on Linux x64 under Xvfb. The native sizing decode returns the same dimensions as the shared header reader and adds measurable synchronous work. The regression test fails on one redundant decode and passes with the fix; the final scoped tests pass 58/58.

Fix: #23129, with runtime evidence and reproduction commands. The real desktop app launches under Xvfb; actual shortcut/accessibility capture and native compositor/scaling integration remain unverified on Linux, macOS, and Windows. The runtime benchmark measures the sizing operation, not full capture latency.