Bug 85318
Summary: | Avoid creating huge layers for large negative text-indent | ||
---|---|---|---|
Product: | WebKit | Reporter: | Simon Fraser (smfr) <simon.fraser> |
Component: | Layout and Rendering | Assignee: | Simon Fraser (smfr) <simon.fraser> |
Status: | NEW | ||
Severity: | Normal | CC: | hyatt, jamesr, mitz, simon.fraser, webkit-bug-importer |
Priority: | P2 | Keywords: | InRadar |
Version: | 528+ (Nightly build) | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
See Also: | https://bugs.webkit.org/show_bug.cgi?id=28348 |
Simon Fraser (smfr)
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)
<rdar://problem/11358685>
Radar WebKit Bug Importer
<rdar://problem/11358702>
Radar WebKit Bug Importer
<rdar://problem/11358704>
Simon Fraser (smfr)
text-indent is considered visual overflow, like shadows.
Simon Fraser (smfr)
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)
Dave pointed me to code in RenderBox::addLayoutOverflow() where 'unreachable' absolute positioned things are detected.
Simon Fraser (smfr)
Negative text-indent is unreachable layout overflow (not visual overflow).
Simon Fraser (smfr)
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)
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)
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