The attached testcase generates a single-line text run that's 200,000 characters long, which matches the text runs we see in the testcase from bug 1506449.

The entire text run gets delivered to WR, and then split with the machinery at [1], even though most of it is off-screen. Gecko has the geometry available, since it's able to deliver a bounding box. So we should use that knowledge to do some culling, which will pay dividends throughout the pipeline.

[1] https://searchfox.org/mozilla-central/rev/b29663c6c9c61b0bf29e8add490cbd6bad293a67/gfx/wr/webrender_api/src/display_list.rs#1130

I'm not sure if we need this for the MVP, since I can do some other mitigations for bug 1506449. Curious for Jeff's thoughts here.

I fixed a subset of this problem in bug 1493353. That detects non-glyph text drawing commands (like pushing an image for the missing glyph symbol) that lie outside the visible region, and culls them.

Doing it for glyphs is a bit harder, since we just get a single bounding box for the entire glyph run and there's no easy way to know which subset of the glyph array lie within the intersection of the visible rect.

The bounding box comes from the display item level, and takes the overflow area of the frame and intersects it with the area that we're building display items for.

The actual code for emitting glyphs is buried deep with the font code, and doesn't appear to have any obvious way to compute the bounding rectangle per glyph.

Maybe there's a way to get an upper bound estimate on any glyph within a given font? I think that's all we'd need to be able to discard glyphs that are clearly well outside the visible area.

Jonathan, do we have anything that would work for this?

We have code in gfx/thebes for per-glyph extents, either "tight" (based on the real glyph shape) or "loose" (based on the glyph's advance and the font's ascent/descent); but I'd be a bit concerned that retrieving extents for every glyph and testing the intersection with the visible rect could prove a bit expensive.

For OpenType fonts, at least, the 'head' table includes xMin/xMax/yMin/yMax fields that give the extremes of the bounding box for any glyph in the font. I don't think we currently expose these, but we could do so; maybe that would help us more quickly discard glyphs that are definitely out of view.

Yeah, according to gw, the bbox field in [1] gives the worst case for any glyph in the font.

[1] https://www.freetype.org/freetype2/docs/reference/ft2-base_interface.html#FT_FaceRec

This seems to work ok right now. Moving to stage-next. We can reprioritize it if the problem shows up in real content.