[BUG] Unnecessary screenshot image scaling degrades model vision #42362

I hit the hardcoded image size limit in the screenshot taking path in playwright-core/lib/coreBundle.js:

function scaleImageToFitMessage(buffer, imageType) {
  ...
  const shrink = Math.min(1568 / image.width, 1568 / image.height, Math.sqrt(1.15 * 1024 * 1024 / pixels));
  ...

This applies a rule that image will be shrunk if any dimension exceeds 1568x1568 bounding box, or if its number of pixels exceeds a square 1098.1x1098.1 pixels in total. That latter logic made it incredibly non-obvious how the ultimate dimensions are determined. It is quite a bomb hidden here in the bowels of the MCP implementation, and worse, non-configurable and I could not find any documentation about this, either.

When it comes to modern model capabilities, the recently released Qwen3.8-27B has the ability to process 4096 image tokens, each which is comprised of 1024 pixels, and so its vision is equivalent to 2048x2048 pixels square, and there are no obvious dimension limits and very narrow and wide images can be provided to the model. Therefore, it seems inescapable to conclude that these limits are much too small in 2026.

Rather than increase these limits, I propose removing the resize algorithm entirely, as it is non-configurable, surprising, likely completely non-documented, and in a place which is hard to find, with rules that make it difficult to discover what logic it is based on. In agentic environments like OpenCode, the program doesn't reveal the details of the images shipped in the chat messages, and to know what size it was received, you have to set a high debug level in LLM software such as llama-server or infer the size from token counts, e.g. that you expected 1600x1200 image to take 1900 tokens, but somehow it was received and was only 760 tokens, instead. (The LLM itself doesn't know either what it sees, it simply receives description of the image as image tokens, and doesn't know their number or anything else about them. However, it can comment whether e.g. small text is readable.)

To control screenshot size, users can simply set up an appropriate viewport size. This means that LLM and human can see the same thing, and the LLM does not appear to be bad because it is operating from a disadvantage which it can't even describe due to lack of introspection.

Finally, I make the point that the scaling should be tailored to the LLM, i.e. have dimensions that align with the vision token boundaries without leaving unused space. Tools like llama-server are in best position to scale the image to fit the token budget of the actual LLM, because it knows all these facts. Therefore, it would be most sensible if no software before the LLM server touches the image, because it is likely to do the wrong thing.

A secondary proposal would be to significantly increase these hard limits to e.g. 4096x4096 in terms of maximum dimensions, so that playwright becomess 4k screen compatible, and having around 2048x2048 limit for pixels. However, doing this creates on-going evaluation and maintenance burden and makes the software worse for no benefit.

Version

└─┬ @playwright/[email protected]
  ├── [email protected]
  └─┬ [email protected]
    ├── UNMET OPTIONAL DEPENDENCY [email protected]
    └── [email protected] deduped