webrender: rendered glyphs corruption (possibly `text-shadow`-related)

[pygy]

Here's a first reduced text case for #9849. Specs: Mac OS X 10.10.5, Intel HD Graphics 4000. Servo last updated seconds ago (thus pulled ~30 min earlier).

This is webrender-only.

Capture:

Live: http://pygy.github.io/servo-rendering-bugs/j2c/j2c/glyphs.html
Source: https://github.com/pygy/servo-rendering-bugs/blob/gh-pages/j2c/j2c/glyphs.html

The oddest thing is that The affected glyphs change from one run to the next. I don't know how you implemented this, but I'll take a guess based on how these things are often done: it looks like the glyph cache is poisoned. The glitch disappears if you remove the h6, its text-shadow or even its font-size.

As you can see the same characters are mangled identically. It isn't visible in the screenshot, but if you scroll further down, you'll see that text whose only difference is a larger font-size is rendered correctly. This leads me to believe that the corruption occurs at the rendered glyph level, rather than at the vector coordinates level.

The glitch isn't always visible. With the example as is, corruption occurs most of the time in the normal-sized <code> elements, and rarley in the <h6> text. Modifying the CSS and/or markup may move the corruption elsewhere.

Please note that webrender also doesn't show the text-shadow.

If memory is corrupted beyond the glyph cache, this may well explain other parts of #9849... I guess the nice thing when you use Rust is that you know where to look when memory is corrupted.

---

[jdm]

cc @glennw @pcwalton

[pygy]

Alternatively, these could be bad reads: the bad <code> glyphs may erroneoulsy be reading the <h6> memory...

[pcwalton]

I suspect undefined behavior, possibly because a texture unit is bound to the current FBO render target.

[pygy]

The full site in #9849 (and its noJS counterpart) change text-shadow on mouseover (Logo and GitHub ribbon).

Hovering these parts of the page cause the glyph glitches to change.

[pygy]

Oddly enough, the latter only occurs when loading the page from my hard disk using file:///...

[nox]

I can't reproduce this anymore.

[pygy]

I can't either with my current machine (a more recent MacBook Air), and I don't have the old one anymore (turns out that driving over a computer is semi-fatal for the poor thing).

[nox]

(turns out that driving over a computer is semi-fatal for the poor thing).

I knew doing issue triage would be worth something, thanks for the good laugh.