1771837 - LA DOTD Map PDFs fail to render correctly with D2D

Status: NEW

(Core :: Graphics, defect)

Description

[Leman Bennett [Omega]]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Firefox/102.0

Steps to reproduce:

Visit this link:
http://wwwsp.dotd.la.gov/Inside_LaDOTD/Divisions/Multimodal/Data_Collection/Mapping/Wall%20Map/Official%20Map%20of%20Louisiana%20-%202021.pdf

Actual results:

The PDF does not render correctly and is missing many details.

Expected results:

Render the PDF the same as Chromium Browsers.

Comment 1

[Hani Yacoub, Desktop QA]

Managed to reproduce the issue on Windows 10 x64, PDF doesn't render correctly.
Can't reproduce it on macOS 11.6 and on Ubuntu 20.04 x64.

Comment 2

[Calixte Denizet (:calixte)]

I confirm the bug on windows 11 but not on mac 12.3.1 so it's very likely not a pdf.js issue but probably something related the Windows graphics backend.
And the pdf is huge (I manage to get Acrobat stuck on it) so it doesn't help to figure out what could be wrong, I'll try to make a reduced test case.
:lsalzman, maybe you'd have an idea, maybe it's another clipping issue.

Comment 3

[Lee Salzman [:lsalzman]]

Are you able to possibly track down a regressing patch with mozregresion to see if this is not something related to recent changes in the Direct2D canvas code?

Comment 4

[Calixte Denizet (:calixte)]

I managed to get this range:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=f5fd13efa844156d6de1ab4bf36ffbeeaf5bc425&tochange=ea38e210ba4d6d14f40cd17fc38515ce7e965e60

Comment 5

[BugBot [:suhaib / :marco/ :calixte]]

:calixte, since this bug is a regression, could you fill (if possible) the regressed_by field?
For more information, please visit auto_nag documentation.

Comment 6

[Lee Salzman [:lsalzman]]

Can you get a smaller regression range? That range is pretty big, and I can't pinpoint what the cause might be from it.

Comment 7

[Calixte Denizet (:calixte)]

Unfortunately, I didn't manage to. It seems that we've only one year of data (except for the builds from archives.m.o).
When I open the pdf in a local build I get a ton of:

Crash Annotation GraphicsCriticalError: |[G0][GFX1-]: [D2D1.1] 4CreateBitmap failure Size(17400,31) Code: 0x80070057 format 0 (t=27.3562) |[G451][GFX1-]: [D2D1.1] 4CreateBitmap failure Size(17400,31) Code: 0x80070057 format 0 (t=154.076) |[G452][GFX1-]: [D2D1.1] 4CreateBitmap failure Size(17400,31) Code: 0x80070057 format 0 (t=154.386) |[G453][GFX1-]: [D2D1.1] 4CreateBitmap failure Size(17400,31) Code: 0x80070057 format 0 (t=154.696) |[G454][GFX1-]: [D2D1.1] 4CreateBitmap failure Size(17400,31) Code: 0x80070057 format 0 (t=155.006) |[G440][GFX1-]: [D2D1.1] 4CreateBitmap failure Size(17400,31) Code: 0x80070057 format 0 (t=150.946) |[G441][GFX1-]: [D2D1.1] 4CreateBitmap failure Size(17400,31) Code: 0x80070057 format 0 (t=151.106) |[G442][GFX1-]: [D2D1.1] 4CreateBitmap failure Size(17400,31) Code: 0x80070057 format 0 (t=151.576) |[G443][GFX1-]: [D2D1.1] 4CreateBitmap failure Size(17400,31) Code: 0x80070057 format 0 (t=151.726) |[G444][GFX1-]: [D2D1.1] 4CreateBitmap failure Size(17400,31) Code: 0x80070057 format 0 (t=152.036) |[G445][GFX1-]: [D2D1.1] 4CreateBitmap failure Size(17400,31) Code: 0x80070057 format 0 (t=152.356) |[G446][GFX1-]: [D2D1.1] 4CreateBitmap failure Size(17400,31) Code: 0x80070057 format 0 (t=152.666) |[G447][GFX1-]: [D2D1.1] 4CreateBitmap failure Size(17400,31) Code: 0x80070057 format 0 (t=152.976) |[G448][GFX1-]: [D2D1.1] 4CreateBitmap failure Size(17400,31) Code: 0x80070057 format 0 (t=153.286) |[G449][GFX1-]: [D2D1.1] 4CreateBitmap failure Size(17400,31) Code: 0x80070057 format 0 (t=153.606) |[G450][GFX1-]: [D2D1.1] 4CreateBitmap failure Size(17400,31) Code: 0x80070057 format 0 (t=153.756) [GFX1-]: [D2D1.1] 4CreateBitmap failure Size(17400,31) Code: 0x80070057 format 0

When I ran mozregression I noticed that this stuff was spit out only with bad builds.

Comment 8

[Lee Salzman [:lsalzman]]

Superficially that just sounds like an OOM situation/invalid allocation size issue. I am not sure if there is much we can do if someone requests a surface that large.

Comment 9

[Calixte Denizet (:calixte)]

It used to work so I suppose it should still be ok, no ?
It works on my macbook pro (which has "only" 16Gb of RAM) but not on my windows (64Gb of RAM).

I know there are some size limits for Canvas:
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/canvas#maximum_canvas_size
but here I've the impress that the requested size is not really out of ranges.
I checked my values in using https://github.com/jhildenbiddle/canvas-size and I get

maxArea(): PASS: 11180 x 11180 (229 ms)
maxHeight(): PASS: 1 x 32767 (4 ms)
maxWidth(): PASS: 32767 x 1 (1 ms)

Comment 10

[Lee Salzman [:lsalzman]]

The Direct2D implementation has its own size limits which may be different from the Skia implementation.

Comment 11

[Calixte Denizet (:calixte)]

For this pdf, I just changed the canvas width from 17400 to 16384 and it works.
And it fails with 16385.

Is there a way to get the limits for the D2D implementation ?

I tested:
https://jsfiddle.net/r2t4bmfx/3/
and it works, could you explain me why ?

Comment 12

[Lee Salzman [:lsalzman]]

Without having a reduced testcase to pinpoint where things are failing, and no reliable regression range, I can't really make a decent guess at the moment.

Comment 13

[Marco Castelluccio [:marco]]

What about bisecting the range with local builds?

Lee, are you able to reproduce the bug yourself?

Comment 14

[Lee Salzman [:lsalzman]]

I am swamped right now, Jeff, can you take a look into this?