Summary: | [chromium] Target surface should be damaged for a new layers even when layer had no changes | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Shawn Singh <shawnsingh> | ||||||||
Component: | Layout and Rendering | Assignee: | Shawn Singh <shawnsingh> | ||||||||
Status: | RESOLVED FIXED | ||||||||||
Severity: | Normal | CC: | backer, cc-bugs, danakj, dglazkov, enne, jamesr, mmocny, nduca, webkit.review.bot | ||||||||
Priority: | P2 | ||||||||||
Version: | 528+ (Nightly build) | ||||||||||
Hardware: | Unspecified | ||||||||||
OS: | Unspecified | ||||||||||
Attachments: |
|
Description
Shawn Singh
2012-03-22 00:35:30 PDT
Created attachment 133200 [details]
Patch
Comment on attachment 133200 [details] Patch Attachment 133200 [details] did not pass chromium-ews (chromium-xvfb): Output: http://queues.webkit.org/results/12072802 Shawn, I really doubt it will matter, but that patch of mine you tried would not have done anything without also applying https://chromiumcodereview.appspot.com/9699125/ to chrome. Is this the iphone page bug? Dana: I dont think so, shawn found this while debugging that issue, but he seemed to think it didnt fix any known issues -- its just the right thing to do(TM). Comment on attachment 133200 [details]
Patch
Out of curiosity, should getting a new parent or being assigned as a mask or replica layer cause "layerPropertyHasChanged()"?
(In reply to comment #3) > Shawn, I really doubt it will matter, but that patch of mine you tried would not have done anything without also applying https://chromiumcodereview.appspot.com/9699125/ to chrome. I guess this suggestion actually applies to http://code.google.com/p/chromium/issues/detail?id=119121 ? OK, I'll try it... And thanks again for the offline discussion yesterday, very helpful. (In reply to comment #4) > Is this the iphone page bug? Nope - as mmocny@ pointed out already =) (In reply to comment #6) > (From update of attachment 133200 [details]) > Out of curiosity, should getting a new parent or being assigned as a mask or replica layer cause "layerPropertyHasChanged()"? probably not, at least not any time soon. Tree manipulations and mask/replica setting occurs during synchronizeTrees and (at least for now) it does that forcibly every time, even when it should not be considered a "change". We could conceivably catch these on the LayerChromium side in a later patch? But I also feel that even if we did do that, this patch is still appropriate. What do you think? Shawn, yes you are right, I meant to post that there. > (In reply to comment #6)
> > (From update of attachment 133200 [details] [details])
> > Out of curiosity, should getting a new parent or being assigned as a mask or replica layer cause "layerPropertyHasChanged()"?
>
> probably not, at least not any time soon. Tree manipulations and mask/replica setting occurs during synchronizeTrees and (at least for now) it does that forcibly every time, even when it should not be considered a "change". We could conceivably catch these on the LayerChromium side in a later patch? But I also feel that even if we did do that, this patch is still appropriate. What do you think?
I think you can if (parent != m_parent) the change. They are not set to 0 or anything AIUI.
(In reply to comment #9) > > (In reply to comment #6) > > > (From update of attachment 133200 [details] [details] [details]) > > > Out of curiosity, should getting a new parent or being assigned as a mask or replica layer cause "layerPropertyHasChanged()"? > > > > probably not, at least not any time soon. Tree manipulations and mask/replica setting occurs during synchronizeTrees and (at least for now) it does that forcibly every time, even when it should not be considered a "change". We could conceivably catch these on the LayerChromium side in a later patch? But I also feel that even if we did do that, this patch is still appropriate. What do you think? > > I think you can if (parent != m_parent) the change. They are not set to 0 or anything AIUI. CCLayerImpl::removeFromParent() does set m_parent to 0 ... and personally I think that's desired behavior, anyway, when thinking about an API of adding/removing nodes from a tree in general. The "correct" solution in my opinion is to make the tree synchronizer avoid unnecessary tree manipulations; but its unclear how hairy and tangled that will become. uploading a new patch in a moment,,, (In reply to comment #10) > (In reply to comment #9) > > > (In reply to comment #6) > > > > (From update of attachment 133200 [details] [details] [details] [details]) > > > > Out of curiosity, should getting a new parent or being assigned as a mask or replica layer cause "layerPropertyHasChanged()"? > > > > > > probably not, at least not any time soon. Tree manipulations and mask/replica setting occurs during synchronizeTrees and (at least for now) it does that forcibly every time, even when it should not be considered a "change". We could conceivably catch these on the LayerChromium side in a later patch? But I also feel that even if we did do that, this patch is still appropriate. What do you think? > > > > I think you can if (parent != m_parent) the change. They are not set to 0 or anything AIUI. > > > CCLayerImpl::removeFromParent() does set m_parent to 0 ... and personally I think that's desired behavior, anyway, when thinking about an API of adding/removing nodes from a tree in general. The "correct" solution in my opinion is to make the tree synchronizer avoid unnecessary tree manipulations; but its unclear how hairy and tangled that will become. Oh! Oops sorry, bad memory. > uploading a new patch in a moment,,, Created attachment 133303 [details]
Should build on linux now
I think if you want to know about tree structure changes on the impl side the right thing to do is to compare layer IDs before/after the sync. They IDs are persistent by design, but the TreeSynchronizer makes no attempt to preserve tree structure (I don't know of an efficient+simple way to do that). (In reply to comment #13) > I think if you want to know about tree structure changes on the impl side the right thing to do is to compare layer IDs before/after the sync. They IDs are persistent by design, but the TreeSynchronizer makes no attempt to preserve tree structure (I don't know of an efficient+simple way to do that). (1) James and Enne, just for clarity to me... are you guys suggesting that we should consider doing that before this patch? If so, I disagree. The more I think about it now, I'm not convinced we'll ever need to make layer properties as changed when the tree structure changes. The damage tracker doesn't care about that, it only cares whether layers are "new", "disappeared" or "the layer is damaged", with respect to its target render surface. (2) "compare layer IDs before / after sync" --> are you suggesting that we look at how the layer ID changed from the "before" snapshot of the tree to the "after" snapshot of the tree? How is that any less complex than detecting changes during tree synchronization? On the other hand, if you mean that we compare layer IDs of the host tree versus the impl tree, before synchronizing, and then mark the appropriate subtrees as "changed" ... that's is not too much different than simply makring layerChromiums as "propertyChanged" and propagating that to the impl side, except the latter would be simpler. Thanks for all the feedback so far =) Comment on attachment 133303 [details] Should build on linux now View in context: https://bugs.webkit.org/attachment.cgi?id=133303&action=review Yeah, I think this does end up being cleaner than marking properties on the layer as changing elsewhere. R=me. > Source/WebKit/chromium/tests/CCDamageTrackerTest.cpp:380 > + ASSERT_EQ(static_cast<size_t>(3), root->renderSurface()->layerList().size()); You can just say "3u" here, if that's easier. Enne, if its OK with you I'll change the static_cast everywhere in CCDamageTrackerTest.cpp when landing. (In reply to comment #16) > Enne, if its OK with you I'll change the static_cast everywhere in CCDamageTrackerTest.cpp when landing. Sounds good! Created attachment 133404 [details]
Patch for landing
Comment on attachment 133404 [details] Patch for landing Clearing flags on attachment: 133404 Committed r111817: <http://trac.webkit.org/changeset/111817> All reviewed patches have been landed. Closing bug. |