Bug 766661 Comment 79 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

We're having issues producing large images with the `:screenshot` command on very long pages and/or when using high resolution DPR values (e.g. `:screenshot --fullpage --dpr 2` and above).

When stressing screenshots in that way, I guess there are multiple things that may fail. Here are some failures I could reproduce with a blank document. Note: I'm using screenshots of the visible content only, so this may not include classes of problems that involve the `--fullpage` option.

## A. Screenshot fails if one dimension is larger than 32767

1. Open in a new tab: `data:text/html,<body style="background:pink"></body>`
2. Open Responsive Design Mode, and set the RDM viewport to width=1000, height=50
3. In Console, run `:screenshot --dpr 32.767`
4. In Console, run `:screenshot --dpr 32.768`

In my tests, step 3 produces a 32767×1638 image, and step 4 fails silently.

## B. Fails if area is larger than X?

With a square viewport, we reach a limit earlier than edge>32767.

1. Open in a new tab: `data:text/html,<body style="background:pink"></body>`
2. Open Responsive Design Mode, and set the RDM viewport to width=1000, height=1000
3. Run `:screenshot --dpr 11.18`
4. Run `:screenshot --dpr 11.181`

#3 works and gives me a 11180×11180 image.
#4 fails silently (expected: a 11181×11181 image).

So what's the difference between #3 and #4?

Expected image dimensions | Number of pixels | Profile
--- | --- | --- | ---
11180 × 11180 | 124,992,400 | https://perfht.ml/2nHVATP
11181 × 11181 | 125,014,761 | https://perfht.ml/2m8b6Iu

It looks like we have a limit at 125,000,000 pixels (or 500MB if 4 bytes per RGBA pixel?).
The profiles also show that #3 takes 900+MB of memory, while #4 is flat, so it's probably failing early on purpose.

If we do this test again with a 1250×1000 viewport, we can run:
- `:screenshot --dpr 9.999` -> 12498×9999 image
- `:screenshot --dpr 10` -> 12500×10000 image (Profile: https://perfht.ml/2mPytGV)
- `:screenshot --dpr 10.001` -> fails silently

## UX considerations

If we don't want or can't change those limits, we should log a message in the Console saying why we can't make a screenshot. Something like:

> Screenshot image is too large. Firefox cannot currently make screenshot images taller than 32767 pixels, or with a pixel count higher than 125 megapixels. Try using the --dpr option with a lower resolution:
> :screenshot --fullpage --dpr 1
We're having issues producing large images with the `:screenshot` command on very long pages and/or when using high resolution DPR values (e.g. `:screenshot --fullpage --dpr 2` and above).

When stressing screenshots in that way, I guess there are multiple things that may fail. Here are some failures I could reproduce with a blank document. Note: I'm using screenshots of the visible content only, so this may not include classes of problems that involve the `--fullpage` option.

## A. Screenshot fails if one dimension is larger than 32767

1. Open in a new tab: `data:text/html,<body style="background:pink"></body>`
2. Open Responsive Design Mode, and set the RDM viewport to width=1000, height=50
3. In Console, run `:screenshot --dpr 32.767`
4. In Console, run `:screenshot --dpr 32.768`

In my tests, step 3 produces a 32767×1638 image, and step 4 fails silently.

## B. Fails if area is larger than X?

With a square viewport, we reach a limit earlier than edge>32767.

1. Open in a new tab: `data:text/html,<body style="background:pink"></body>`
2. Open Responsive Design Mode, and set the RDM viewport to width=1000, height=1000
3. Run `:screenshot --dpr 11.18`
4. Run `:screenshot --dpr 11.181`

#3 works and gives me a 11180×11180 image.
#4 fails silently (expected: a 11181×11181 image).

So what's the difference between #3 and #4?

Expected image dimensions | Number of pixels | Profile
--- | --- | ---
11180 × 11180 | 124,992,400 | https://perfht.ml/2nHVATP
11181 × 11181 | 125,014,761 | https://perfht.ml/2m8b6Iu

It looks like we have a limit at 125,000,000 pixels (or 500MB if 4 bytes per RGBA pixel?).
The profiles also show that #3 takes 900+MB of memory, while #4 is flat, so it's probably failing early on purpose.

If we do this test again with a 1250×1000 viewport, we can run:
- `:screenshot --dpr 9.999` -> 12498×9999 image
- `:screenshot --dpr 10` -> 12500×10000 image (Profile: https://perfht.ml/2mPytGV)
- `:screenshot --dpr 10.001` -> fails silently

## UX considerations

If we don't want or can't change those limits, we should log a message in the Console saying why we can't make a screenshot. Something like:

> Screenshot image is too large. Firefox cannot currently make screenshot images taller than 32767 pixels, or with a pixel count higher than 125 megapixels. Try using the --dpr option with a lower resolution:
> :screenshot --fullpage --dpr 1

Back to Bug 766661 Comment 79