Closed Bug 1410613 Opened 7 years ago Closed 6 years ago

Intermittent w3c-css/received/css-writing-modes-3/bidi-embed-002.html == w3c-css/received/css-writing-modes-3/reference/bidi-embed-002.html | image comparison, max difference: 255, number of differing pixels: 184

Categories

(Core :: Graphics: Text, defect, P5)

Product:
Core
Component:
Graphics: Text
Type:
defect

Tracking

()

Status:
RESOLVED INCOMPLETE

People

(Reporter: intermittent-bug-filer, Unassigned)

References

Details

(Keywords: intermittent-failure, Whiteboard: [gfx-noted]) 

Looks like something fails to access a piece of info to determine the bonding box (of a particular glyph? probably 'a' in the log that I looked at) the first time, with this error printed in the log:

> Could not create glyph run analysis.
> z:/build/build/src/gfx/skia/skia/src/ports/SkScalerContext_win_dw.cpp(508) : error 0x80070005: Access is denied.
> Requested bounding box could not be determined.
> z:/build/build/src/gfx/skia/skia/src/ports/SkScalerContext_win_dw.cpp(583) : error 0x80070005: Access is denied.

And subsequent attempts to render that glyph under some condition fail.

Lee, does that ring any bell?
Flags: needinfo?(lsalzman)
Whiteboard: [gfx-noted]
Really no idea here. It's happening inside IDWriteFactory::CreateGlyphRunAnalysis. Yet, it's proceeding fine for some characters but not others. But maybe they're ending up using different fonts. Even so, I'm not familiar with why CreateGlyphRunAnalysis would only intermittently fail. The 0x80070005 HRESULT/"Access is denied" is just weird, as intermittents go...

Jonathan or Bas, ideas?
Flags: needinfo?(lsalzman)
Flags: needinfo?(jfkthame)
Flags: needinfo?(bas)
No idea, sorry. Looking at the reftest-analyzer view from comment 0, perhaps the weirdest case is the reference file for layout/reftests/w3c-css/received/css-writing-modes-3/reference/block-override-004.html, where two occurrences of "a" are missing, while four other occurrences of the same glyph are rendered fine. (They should all be rendered from the exact same font.)

The one difference I can see between the missing "a"s and the ones that are present is that they're at different subpixel alignments (if you look at the testcase, where they're all visible, the antialiasing is slightly different on these two from the other four). So that implies the rendering involves two distinct rasterizations or cachings of "a" for different fractional positions, and in the case of the reference rendering (but not the testcase), one of those apparently failed.

But why? I have no clue.
Flags: needinfo?(jfkthame)
Status: NEW → RESOLVED
Closed: 6 years ago
Flags: needinfo?(bas)
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.