A blinking caret in an input text filed, maybe ? It's very common on the web, the number of pixels that needs to be repainted is very small and it happens somewhat continuously, so invalidating only the few pixels around the caret ends up saving a lot over a minute.
Cheers, Nical On Tue, Oct 28, 2014 at 10:45 PM, Patrick Walton <pcwal...@mozilla.com> wrote: > On 10/28/14 2:40 PM, Robert O'Callahan wrote: > >> OK, but I still have the general question of how your overflow-based >> invalidation handles reflows. The basic problem is style changes to >> element A can result in geometry changes to element B where B is not a >> descendant of A. For example suppose <body> contains two DIV children A >> and B and something changes the height of A so B moves down. How does >> overflow-based invalidation ensure B is repainted? >> > > In that case you have a change in "absolute position"† of B, which is > computed as a top-down pass (with DL building on the way back up), which > would cause an invalidation. So it's not just overflow regions that we use, > it's overflow regions plus absolute position. > > Patrick > > † Which is really not a good name--we should call it "page position" or > something to avoid the obvious name clash with the unrelated CSS concept. > > > _______________________________________________ > dev-servo mailing list > dev-servo@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-servo > _______________________________________________ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
