WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
125263
Bad repaints on Twitter when the tile cache has a margin
https://bugs.webkit.org/show_bug.cgi?id=125263
Summary
Bad repaints on Twitter when the tile cache has a margin
Beth Dakin
Reported
2013-12-04 15:43:59 PST
With the new backgroundShouldExtendBeyondPage() Setting, there are painting artifacts on Twitter and other webpages that grow their contents size. <
rdar://problem/15576884
>
Attachments
Patch
(2.84 KB, patch)
2013-12-04 15:46 PST
,
Beth Dakin
thorton
: review+
Details
Formatted Diff
Diff
View All
Add attachment
proposed patch, testcase, etc.
Beth Dakin
Comment 1
2013-12-04 15:46:32 PST
Created
attachment 218468
[details]
Patch
Tim Horton
Comment 2
2013-12-04 16:22:24 PST
Comment on
attachment 218468
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=218468&action=review
> Source/WebCore/platform/graphics/ca/mac/TileController.mm:755 > + // If there are magin tiles and the bounds have grown taller or wider, then the tiles that used to
margin
> Source/WebCore/platform/graphics/ca/mac/TileController.mm:761 > + IntRect boundsWithoutMargin = IntRect(IntPoint(), expandedIntSize(m_tileCacheLayer->bounds().size())); > + IntRect oldBoundsWithoutMargin = IntRect(IntPoint(), m_boundsAtLastRevalidate.size()); > + oldBoundsWithoutMargin.contract(IntSize(leftMarginWidth() + rightMarginWidth(), topMarginHeight() + bottomMarginHeight()));
it might be nice if these things were factored out, especially the things that are done elsewhere
> Source/WebCore/platform/graphics/ca/mac/TileController.mm:763 > + if (bounds.height() > m_boundsAtLastRevalidate.height()) {
smfr mentioned when things get shorter/skinnier, and you said that it didn't seem to be an issue, but I wonder why? what is invalidating the layer in that case? why doesn't it have stale content? would be nice to have a clear understanding.
Beth Dakin
Comment 3
2013-12-05 09:50:42 PST
(In reply to
comment #2
)
> (From update of
attachment 218468
[details]
) > View in context:
https://bugs.webkit.org/attachment.cgi?id=218468&action=review
> > > Source/WebCore/platform/graphics/ca/mac/TileController.mm:755 > > + // If there are magin tiles and the bounds have grown taller or wider, then the tiles that used to > > margin >
Hehe
> > Source/WebCore/platform/graphics/ca/mac/TileController.mm:761 > > + IntRect boundsWithoutMargin = IntRect(IntPoint(), expandedIntSize(m_tileCacheLayer->bounds().size())); > > + IntRect oldBoundsWithoutMargin = IntRect(IntPoint(), m_boundsAtLastRevalidate.size()); > > + oldBoundsWithoutMargin.contract(IntSize(leftMarginWidth() + rightMarginWidth(), topMarginHeight() + bottomMarginHeight())); > > it might be nice if these things were factored out, especially the things that are done elsewhere >
Will do.
> > Source/WebCore/platform/graphics/ca/mac/TileController.mm:763 > > + if (bounds.height() > m_boundsAtLastRevalidate.height()) { > > smfr mentioned when things get shorter/skinnier, and you said that it didn't seem to be an issue, but I wonder why? what is invalidating the layer in that case? why doesn't it have stale content? would be nice to have a clear understanding.
I did some debugging here and Tim and I talked about it in person. Basically it seems like the cached repaint rects in the GraphicsLayerCA class always seem to have a repaint rect equivalent to the "old" size in changing-content-size test cases. So when the content goes from small to large, there is a small repaint rect that doesn't cover everything. Normal content ends up being fine due to other normal-content invalidations. When the page goes from large to small there is a large repaint rect that is big enough to cover the margin.
Beth Dakin
Comment 4
2013-12-05 09:54:48 PST
Thanks Tim!
http://trac.webkit.org/changeset/160179
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug