WebKit Bugzilla
New
Browse
Search+
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
73270
[Chromium] Early returns in calculateDrawTransformsAndVisibilityInternal() can leave layers with stale render surfaces
https://bugs.webkit.org/show_bug.cgi?id=73270
Summary
[Chromium] Early returns in calculateDrawTransformsAndVisibilityInternal() ca...
Daniel Sievers
Reported
2011-11-28 17:16:33 PST
[Chromium] Early returns in calculateDrawTransformsAndVisibilityInternal() can leave layers with stale render surfaces
Attachments
Patch
(3.54 KB, patch)
2011-11-28 17:16 PST
,
Daniel Sievers
no flags
Details
Formatted Diff
Diff
Patch
(8.39 KB, patch)
2011-11-30 18:50 PST
,
Daniel Sievers
no flags
Details
Formatted Diff
Diff
Patch
(8.41 KB, patch)
2011-11-30 18:52 PST
,
Daniel Sievers
no flags
Details
Formatted Diff
Diff
Patch
(9.29 KB, patch)
2011-12-01 01:03 PST
,
Daniel Sievers
no flags
Details
Formatted Diff
Diff
Show Obsolete
(3)
View All
Add attachment
proposed patch, testcase, etc.
Daniel Sievers
Comment 1
2011-11-28 17:16:59 PST
Created
attachment 116855
[details]
Patch
Daniel Sievers
Comment 2
2011-11-28 17:37:05 PST
Note that the first EXPECT_EQ() actually currently passes. EXPECT_EQ(renderSurfaceLayerList.size(), 0U); ASSERT_FALSE(renderSurface1->renderSurface()); However, the layer still has a stale render surface even if it might end up being drawn onto another render surface now (i.e. root layer). The texture residency logic seems to not really like this. We might assert that the texture is currently not protected early on (even if there is nothing to draw), because we expect any referenced render surfaces to have been processed before as part of the same frame.
Adrienne Walker
Comment 3
2011-11-29 09:16:37 PST
Isn't the problem that renderSurface1 appears in a layer list but doesn't appear in the render surface list? That seems to me like the invariant that this test should be testing. I don't know that we're always going to clear render surfaces from every layer. For instance, we skip entire layer subtrees if we know that they're not going to get drawn.
Daniel Sievers
Comment 4
2011-11-29 14:49:18 PST
(In reply to
comment #3
)
> Isn't the problem that renderSurface1 appears in a layer list but doesn't appear in the render surface list? That seems to me like the invariant that this test should be testing. >
Are you talking about the test in general or just the concluding checks? I guess the test shows one case (for the !drawOpacity early-return) that is currently broken. When making the layer transparent the scenario you describe is the case...
> I don't know that we're always going to clear render surfaces from every layer. For instance, we skip entire layer subtrees if we know that they're not going to get drawn.
...so should I change it to something like: // After the second pass and having made the layer fully transparent, we expect the // intermediate render surface to have been removed. The layer should now be drawn onto // the root render surface. It's important that a given render surface's layer list does // not reference other render surfaces which are not part of renderSurfaceLayerList for // the current frame (as the content texture residency logic relies on it). EXPECT_EQ(parent->renderSurface()->layerList().size(), 1U); EXPECT_EQ(parent->renderSurface()->layerList()[0].get(), renderSurface1.get()); EXPECT_EQ(renderSurfaceLayerList.size(), 0U); EXPECT_NE(renderSurface1->renderSurface(), surface);
Daniel Sievers
Comment 5
2011-11-29 14:50:14 PST
> EXPECT_NE(renderSurface1->renderSurface(), surface);
surface being the old value of the initial extra render surface created for the layer before.
Adrienne Walker
Comment 6
2011-11-29 16:38:16 PST
> EXPECT_EQ(parent->renderSurface()->layerList().size(), 1U); > EXPECT_EQ(parent->renderSurface()->layerList()[0].get(), renderSurface1.get()); > EXPECT_EQ(renderSurfaceLayerList.size(), 0U); > EXPECT_NE(renderSurface1->renderSurface(), surface);
What you wrote above is what I would expect from the current code.
> EXPECT_EQ(parent->renderSurface()->layerList().size(), 0); > EXPECT_EQ(renderSurfaceLayerList.size(), 0);
This is what I would expect if the code were correct.
Daniel Sievers
Comment 7
2011-11-30 18:50:18 PST
Created
attachment 117309
[details]
Patch
Daniel Sievers
Comment 8
2011-11-30 18:52:21 PST
Created
attachment 117310
[details]
Patch
Adrienne Walker
Comment 9
2011-11-30 19:03:11 PST
Comment on
attachment 117309
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=117309&action=review
> Source/WebCore/platform/graphics/chromium/cc/CCLayerTreeHostCommon.cpp:368 > + if (drawsContent) {
This is great. It looks like this also fixes a bug where layers that don't get drawn were still influencing the drawable content rect size.
WebKit Review Bot
Comment 10
2011-11-30 23:03:20 PST
Comment on
attachment 117310
[details]
Patch Rejecting
attachment 117310
[details]
from commit-queue. Failed to run "['/mnt/git/webkit-commit-queue/Tools/Scripts/webkit-patch', '--status-host=queues.webkit.org', '-..." exit_code: 2 Last 500 characters of output: ng file Source/WebCore/platform/graphics/chromium/cc/CCLayerTreeHostCommon.cpp Hunk #4 FAILED at 389. Hunk #5 succeeded at 454 (offset -2 lines). 1 out of 5 hunks FAILED -- saving rejects to file Source/WebCore/platform/graphics/chromium/cc/CCLayerTreeHostCommon.cpp.rej patching file Source/WebKit/chromium/tests/CCLayerTreeHostCommonTest.cpp Hunk #1 succeeded at 481 with fuzz 1 (offset 29 lines). Failed to run "[u'/mnt/git/webkit-commit-queue/Tools/Scripts/svn-apply', u'--force']" exit_code: 1 Full output:
http://queues.webkit.org/results/10687517
James Robinson
Comment 11
2011-11-30 23:07:19 PST
Can you rebase this patch to ToT, Daniel?
Daniel Sievers
Comment 12
2011-12-01 01:03:41 PST
Created
attachment 117375
[details]
Patch
Daniel Sievers
Comment 13
2011-12-01 01:05:23 PST
Done. I've also added this check to the unit test to make sure we don't expand the parent's drawable content rect from the children that are not drawing: EXPECT_EQ(parent->drawableContentRect(), IntRect()); (In reply to
comment #11
)
> Can you rebase this patch to ToT, Daniel?
WebKit Review Bot
Comment 14
2011-12-01 13:45:10 PST
Comment on
attachment 117375
[details]
Patch Clearing flags on attachment: 117375 Committed
r101702
: <
http://trac.webkit.org/changeset/101702
>
WebKit Review Bot
Comment 15
2011-12-01 13:45:15 PST
All reviewed patches have been landed. Closing bug.
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