Closed Bug 1390365 Opened 7 years ago Closed 6 years ago

Intermittent css-writing-modes-3/baseline-inline-non-replaced-002.xht == w3c-css/received/reference/ref-filled-green-100px-square.xht | image comparison, max difference: 255, number of differing pixels: 48 ('n' is missing from "no" in the screenshots)

Categories

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

Product:
Core
Component:
Graphics: Text
Platform:
x86
Windows 7
Type:
defect

Tracking

()

Status:
RESOLVED INCOMPLETE

People

(Reporter: intermittent-bug-filer, Unassigned)

References

Details

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

Component: Layout → Graphics: Text
OS: Unspecified → Windows 7
Hardware: Unspecified → x86
Fascinating, the reftest also really isn't that complicated, there doesn't seem to be anything special about that line or its rendering, Jonathan, you talked to me about glyph bounding boxes recently, any chance you were looking at something remotely related to this?
Flags: needinfo?(jfkthame)
Whiteboard: [gfx-noted]
(In reply to Bas Schouten (:bas.schouten) from comment #4)
> Fascinating, the reftest also really isn't that complicated, there doesn't
> seem to be anything special about that line or its rendering, Jonathan, you
> talked to me about glyph bounding boxes recently, any chance you were
> looking at something remotely related to this?

No, I don't think that was relevant to this. (AFAICS, that code isn't actually in use at present.) This one seems particularly puzzling; I can't see any reason why one glyph in the text run should fail to render, when the rest of it is fine.

It's interesting, though, that it happens to be the first glyph we're trying to render with that font. Is it possible there's some kind of race condition involved with sending the font over to the rendering process, whereby it's not actually quite ready to use when we try to start drawing the text? (I don't really know anything about the current rendering architecture and how we manage font resources there... I think that's more Lee's thing.)
Flags: needinfo?(jfkthame) → needinfo?(lsalzman)
(In reply to Jonathan Kew (:jfkthame) from comment #5)
> (In reply to Bas Schouten (:bas.schouten) from comment #4)
> > Fascinating, the reftest also really isn't that complicated, there doesn't
> > seem to be anything special about that line or its rendering, Jonathan, you
> > talked to me about glyph bounding boxes recently, any chance you were
> > looking at something remotely related to this?
> 
> No, I don't think that was relevant to this. (AFAICS, that code isn't
> actually in use at present.) This one seems particularly puzzling; I can't
> see any reason why one glyph in the text run should fail to render, when the
> rest of it is fine.
> 
> It's interesting, though, that it happens to be the first glyph we're trying
> to render with that font. Is it possible there's some kind of race condition
> involved with sending the font over to the rendering process, whereby it's
> not actually quite ready to use when we try to start drawing the text? (I
> don't really know anything about the current rendering architecture and how
> we manage font resources there... I think that's more Lee's thing.)

In principle this should all be happening in the content process. Fonts aren't getting sent over, rather the result of rasterization will get sent over. So whatever is going wrong here is thus in the content process. I wouldn't think races would be involved.

What is strange is the Windows 7 32-bit limitation on occurrences of this intermittent. I wonder if this is somehow related to the glyph cache in Skia.

I would really need a reliable way of reproduce this though to track this down. The fact that it is seemingly also happening only on Windows 7 32-bit makes it additionally painful.
Flags: needinfo?(lsalzman)
See Also: → 1438422
https://wiki.mozilla.org/Bug_Triage#Intermittent_Test_Failure_Cleanup
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.