Avoid creating huge layers for large negative text-indent 
https://bugs.webkit.org/show_bug.cgi?id=85318
Summary Avoid creating huge layers for large negative text-indent
Simon Fraser (smfr)
Reported 2012-05-01 15:32:14 PDT
Many sites use CSS like text-indent: -9999px as an image replacement technique <http://css-tricks.com/css-image-replacement/>. However, this often results in compositing layers being huge, since we make the layers large enough to contain that offset text. We should add some smarts to detect whether the text-indent pushes the text outside the viewport, and avoid the stupidly large layers in that case.
Attachments
Add attachment proposed patch, testcase, etc.
Simon Fraser (smfr)
Comment 1 2012-05-01 15:33:13 PDT
<rdar://problem/11358685>
Radar WebKit Bug Importer
Comment 2 2012-05-01 15:33:38 PDT
<rdar://problem/11358702>
Radar WebKit Bug Importer
Comment 3 2012-05-01 15:33:41 PDT
<rdar://problem/11358704>
Simon Fraser (smfr)
Comment 4 2012-05-01 15:36:16 PDT
text-indent is considered visual overflow, like shadows.
Simon Fraser (smfr)
Comment 5 2012-05-01 17:11:30 PDT
Some thoughts here: * set a bit on RO's whose visual overflow encompasses things with large negative text-indent * when computing compositing layer bounds don't use visual overflow, but compute bounds excluding the effect of text-indent on certain nodes or * add a more fine-grained notion of which bits of a line need to paint when something changes (visual overflow on steroids). Use this to exclude parts which will never paint. or * use information from painting to optimize layer bounds to exclude never-painted areas.
Simon Fraser (smfr)
Comment 6 2012-05-04 11:19:27 PDT
Dave pointed me to code in RenderBox::addLayoutOverflow() where 'unreachable' absolute positioned things are detected.
Simon Fraser (smfr)
Comment 7 2012-05-04 11:20:54 PDT
Negative text-indent is unreachable layout overflow (not visual overflow).
Simon Fraser (smfr)
Comment 8 2012-05-04 11:39:18 PDT
dhyatt: you detect that the box is all the way outside [11:35am] dhyatt: so the visual overflow of say a render block that holds one of these problem lines [11:35am] dhyatt: will just be the render block's dimensions [11:36am] dhyatt: i'm saying imagine that the addLayoutOverflow code in RenderBox both works with line boxes [11:36am] dhyatt: instead of just child renderobjects [11:36am] smfr: oh i see i think [11:36am] dhyatt: and is also applied aggressively [11:36am] dhyatt: rather than waiting for you to "get up to the viewport" [11:36am] smfr: you use the viewport sides to detect unreachability [11:36am] dhyatt: right [11:36am] smfr: got it [11:36am] dhyatt: and just fix it right then and there [11:36am] dhyatt: honestly i think you can do the same thing if you hit an overflow section as well [11:36am] smfr: have to be careful with accelerated transitions [11:36am] dhyatt: my only concern with this of course is will this make overflow O(n^2) in tree depth
Simon Fraser (smfr)
Comment 9 2012-05-04 11:46:04 PDT
dhyatt: you could also just do some gross hack [11:38am] dhyatt: if text indent is a large enough negative value just discount a line from contributing to overflow [11:38am] smfr: yeah, but I think you'd have to take the text length into account [11:38am] dhyatt: kind of gross though to do a hack since it would be possible to make ap age that broke [11:38am] smfr: someone might want to transition in a long line from the left [11:38am] dhyatt: yeah [11:39am] dhyatt: and it may become visible before it is in your box [11:39am] dhyatt: if your box is shifted over [11:40am] dhyatt: anyway you could do unreachability more agressively [11:40am] dhyatt: aggressively [11:40am] dhyatt: rather than waiting for the propagation up [11:41am] dhyatt: but i suspect i waited til you got to the clipping render object (e.g., overflow or viewport) for performance [11:41am] dhyatt: since it's just O(1) to look at the coordinates then [11:41am] dhyatt: we do have layout state pushing offsets though [11:41am] dhyatt: dunno how accurate they would be [11:41am] smfr: yeah, who knows if the offsets are viewport-relative [11:41am] dhyatt: but in theory could use those to know where you are relative to viewport quickly [11:41am] smfr: there's no guarantee of that, right? [11:42am] dhyatt: and i think we pop layout state before computing overflow [11:42am] smfr: hm [11:42am] dhyatt: so that would be my concern [11:42am] dhyatt: is that you'd be crawling up [11:42am] dhyatt: then again [11:42am] dhyatt: hmm [11:42am] dhyatt: you could limit the crawl by detecting first [11:42am] dhyatt: if the object is unreachable from *your* box [11:43am] dhyatt: i.e., if it's outside your render box completely [11:43am] dhyatt: and if so [11:43am] dhyatt: then try to figure out if it's also outside the viewport [11:43am] dhyatt: then you would only be doing this for a very small set of objects [11:43am] smfr: yeah
Simon Fraser (smfr)
Comment 10 2012-05-04 11:53:39 PDT
dhyatt: so yeah something like "hey this line is totally outside of my box" [11:47am] dhyatt: "why don't i see if it's outside the viewport too" [11:48am] dhyatt: void RenderBlock::addOverflowFromInlineChildren() [11:48am] dhyatt: is the method you'll be patching i think [11:49am] dhyatt: just check if the visual overflow rect of the line box is outside in a direction that lines up with an unreachable viewport direction
Note You need to log in before you can comment on or make changes to this bug.