Chromium Code Reviews
|
|
Chromium Code Reviews
Issue
11567034:
Changes subtreeShouldRenderToSeparateSurface logic to account for explicit clipping (Closed)
|
Created:
8 years ago by whunt Modified:
7 years, 11 months ago CC:
chromium-reviews, cc-bugs_chromium.org Base URL:
svn://svn.chromium.org/chrome/trunk/src Visibility:
Public. |
DescriptionThis patch prevents the creation of some render targets by informing the logic that determines if a sub-tree needs an intermediate render target about the ability of descendants in its sub-tree ability to clip themselves.
BUG=
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=175919
Patch Set 1 #
Total comments: 11
Patch Set 2 : Reworking the test for creating a layer, should work correctly now. #
Total comments: 5
Patch Set 3 : removed unused function and changed tracking variable from int to bool #Patch Set 4 : re-adding a previously removed check of the transforms between a layer and its child #
Total comments: 10
Patch Set 5 : moving IsPositiveScaleOrTranslation into gfx::Transform #
Total comments: 6
Patch Set 6 : adding a unit test and renaming adding a unit test and renaming can_clip_self" #
Total comments: 15
Patch Set 7 : Addressing Shawn's feedback. #
Total comments: 7
Patch Set 8 : addressing Dana's feedback #
Total comments: 1
Patch Set 9 : merge up to tip of tree #Patch Set 10 : addressing new style constraints on virtual inline functions #Patch Set 11 : more style-complience updates #Patch Set 12 : small style requirements update #Patch Set 13 : merging to tip of tree #Patch Set 14 : another inline virtual change #Patch Set 15 : very minor change #
Messages
Total messages: 33 (0 generated)
It appears to make the perspective case in the tab switcher much faster and I haven't noticed any artifacts. I guess the try-bots will let us know if I broke anything in the process.
https://codereview.chromium.org/11567034/diff/1/cc/layer_tree_host_common.cc File cc/layer_tree_host_common.cc (right): https://codereview.chromium.org/11567034/diff/1/cc/layer_tree_host_common.cc#... cc/layer_tree_host_common.cc:438: float x_scale = xform.matrix().getDouble(0,0); do we have to do a double->float conversion here? I suspect it'll compile away, but since the transform is double and we don't need to do anything but a sign comparison seems better to keep this doubles https://codereview.chromium.org/11567034/diff/1/cc/layer_tree_host_common.cc#... cc/layer_tree_host_common.cc:454: bool sublayerPreventsClip = !isPositiveScaleOrTranslation(layer->sublayerTransform()); I'm not sure that this is sufficient. If the transform on the clipping layer is a (for instance) rotation then we can clip a texutre_layer_impl, but we don't have any code (afaik) to clip other types of layers
https://codereview.chromium.org/11567034/diff/1/cc/draw_properties.h File cc/draw_properties.h (right): https://codereview.chromium.org/11567034/diff/1/cc/draw_properties.h#newcode59 cc/draw_properties.h:59: bool all_children_can_clip; We should definitely add another line to the DrawProperties constructor defined above, to initialize this correctly. https://codereview.chromium.org/11567034/diff/1/cc/layer_tree_host_common.cc File cc/layer_tree_host_common.cc (right): https://codereview.chromium.org/11567034/diff/1/cc/layer_tree_host_common.cc#... cc/layer_tree_host_common.cc:454: bool sublayerPreventsClip = !isPositiveScaleOrTranslation(layer->sublayerTransform()); +1 james comment; we do need the additional condition that prevents sublayerPreventsClip from being true unless the layer is the correct type, right? also, naming nit: sublayerPreventsClip --> descendantPreventsClip https://codereview.chromium.org/11567034/diff/1/cc/layer_tree_host_common.cc#... cc/layer_tree_host_common.cc:461: numChildDescendantsThatDrawContent += childLayer->drawsContent() ? 1 : 0; I'm not sure about this rename, how about we omit this particular change from this patch and discuss it later? no functionality changed here, right?
https://codereview.chromium.org/11567034/diff/1/cc/layer_tree_host_common.cc File cc/layer_tree_host_common.cc (right): https://codereview.chromium.org/11567034/diff/1/cc/layer_tree_host_common.cc#... cc/layer_tree_host_common.cc:454: bool sublayerPreventsClip = !isPositiveScaleOrTranslation(layer->sublayerTransform()); On 2012/12/14 04:31:19, jamesr wrote: > I'm not sure that this is sufficient. If the transform on the clipping layer is > a (for instance) rotation then we can clip a texutre_layer_impl, but we don't > have any code (afaik) to clip other types of layers Sorry for the drive-by, but I wanted to mention that we should probably add SkMatrix44::preservesAxisAlignment to match the already existing SkMatrix:: preservesAxisAlignment. I think this would suit your needs here. Implementing the SkMatrix44 method should be pretty simple, I think -- correct me if I'm wrong, but if in the upper-left 3x3 matrix there are only 3 non-zero entries, one in each row, and one in each column, I think we're ok?
I'm thinking this would be something worth doing after branch? We probably want to try and land this particular patch today, if possible. If you like, please feel free to create a crbug about this and assign it to me so we don't forget about it =)
On Fri, Dec 14, 2012 at 4:02 AM, <[email protected]> wrote: > > https://codereview.chromium.org/11567034/diff/1/cc/layer_tree_host_common.cc > File cc/layer_tree_host_common.cc (right): > > https://codereview.chromium.org/11567034/diff/1/cc/layer_tree_host_common.cc#... > cc/layer_tree_host_common.cc:454: bool sublayerPreventsClip = > !isPositiveScaleOrTranslation(layer->sublayerTransform()); > On 2012/12/14 04:31:19, jamesr wrote: >> >> I'm not sure that this is sufficient. If the transform on the > > clipping layer is >> >> a (for instance) rotation then we can clip a texutre_layer_impl, but > > we don't >> >> have any code (afaik) to clip other types of layers > > > Sorry for the drive-by, but I wanted to mention that we should probably > add SkMatrix44::preservesAxisAlignment to match the already existing > SkMatrix:: preservesAxisAlignment. I think this would suit your needs > here. Implementing the SkMatrix44 method should be pretty simple, I > think -- correct me if I'm wrong, but if in the upper-left 3x3 matrix > there are only 3 non-zero entries, one in each row, and one in each > column, I think we're ok? FYI http://code.google.com/p/skia/issues/detail?id=1017
https://codereview.chromium.org/11567034/diff/1/cc/draw_properties.h File cc/draw_properties.h (right): https://codereview.chromium.org/11567034/diff/1/cc/draw_properties.h#newcode59 cc/draw_properties.h:59: bool all_children_can_clip; I'm happy to do this but I object to the word "definitely". This value is always initialized in the pre-walk before it is used. If it's not initialized there it's pretty meaningless. Also we've already defined it to be meaningless if is_clipped is false, which is set by default. Also, it's not clear what the correct default value should be. I can set it to false but again, that's not really any more meaningful than undefined. On 2012/12/14 07:34:44, shawnsingh wrote: > We should definitely add another line to the DrawProperties constructor defined > above, to initialize this correctly. https://codereview.chromium.org/11567034/diff/1/cc/layer_tree_host_common.cc File cc/layer_tree_host_common.cc (right): https://codereview.chromium.org/11567034/diff/1/cc/layer_tree_host_common.cc#... cc/layer_tree_host_common.cc:438: float x_scale = xform.matrix().getDouble(0,0); There's no reason to do the conversion. I'm just used to assuming things are floats. I'll chnage it. On 2012/12/14 04:31:19, jamesr wrote: > do we have to do a double->float conversion here? I suspect it'll compile away, > but since the transform is double and we don't need to do anything but a sign > comparison seems better to keep this doubles https://codereview.chromium.org/11567034/diff/1/cc/layer_tree_host_common.cc#... cc/layer_tree_host_common.cc:454: bool sublayerPreventsClip = !isPositiveScaleOrTranslation(layer->sublayerTransform()); I'm aware this isn't sufficient. I'm working on fixing it. I just wanted to get the ball rolling. On 2012/12/14 04:31:19, jamesr wrote: > I'm not sure that this is sufficient. If the transform on the clipping layer is > a (for instance) rotation then we can clip a texutre_layer_impl, but we don't > have any code (afaik) to clip other types of layers https://codereview.chromium.org/11567034/diff/1/cc/layer_tree_host_common.cc#... cc/layer_tree_host_common.cc:454: bool sublayerPreventsClip = !isPositiveScaleOrTranslation(layer->sublayerTransform()); The clipper wont work on rotations by 90 degrees so the functionality isn't the same. On 2012/12/14 12:02:16, vollick wrote: > On 2012/12/14 04:31:19, jamesr wrote: > > I'm not sure that this is sufficient. If the transform on the clipping layer > is > > a (for instance) rotation then we can clip a texutre_layer_impl, but we don't > > have any code (afaik) to clip other types of layers > > Sorry for the drive-by, but I wanted to mention that we should probably add > SkMatrix44::preservesAxisAlignment to match the already existing SkMatrix:: > preservesAxisAlignment. I think this would suit your needs here. Implementing > the SkMatrix44 method should be pretty simple, I think -- correct me if I'm > wrong, but if in the upper-left 3x3 matrix there are only 3 non-zero entries, > one in each row, and one in each column, I think we're ok? https://codereview.chromium.org/11567034/diff/1/cc/layer_tree_host_common.cc#... cc/layer_tree_host_common.cc:461: numChildDescendantsThatDrawContent += childLayer->drawsContent() ? 1 : 0; I need the intermediate value. I didn't change your variables name. Look at the code more closely. On 2012/12/14 07:34:44, shawnsingh wrote: > I'm not sure about this rename, how about we omit this particular change from > this patch and discuss it later? no functionality changed here, right?
https://codereview.chromium.org/11567034/diff/8001/cc/draw_properties.h File cc/draw_properties.h (right): https://codereview.chromium.org/11567034/diff/8001/cc/draw_properties.h#newco... cc/draw_properties.h:28: , num_descendants_that_draw_content_and_cant_clip_themselves(0) Hmm, what a mouthful! I don't think we need a count here, we just need a bool. For num_desc.._that_draw_content we need a count since we have different behavior for 0, 1, and 2+. For clipping we only care about 0 and 1+ I think this might be shorter and clearer still if it was phrased as a positive rather than a negative - i.e. "can_clip_self" or something like that? https://codereview.chromium.org/11567034/diff/8001/cc/layer_tree_host_common.cc File cc/layer_tree_host_common.cc (right): https://codereview.chromium.org/11567034/diff/8001/cc/layer_tree_host_common.... cc/layer_tree_host_common.cc:433: inline bool isPositiveScaleOrTranslation(const gfx::Transform& xform) is there a caller to this function? I can't find it. Can we share the logic that's common between this function and TextureDrawQuad::PerformClipping() ? the two need to have the same return values for correctness, and I suspect we'll want to make the clipping more general over time, so if we can factor this into a shared function we'll only have one thing to update rather than two things that we have to keep in sync with each other https://codereview.chromium.org/11567034/diff/8001/cc/layer_tree_host_common.... cc/layer_tree_host_common.cc:439: double x_scale = xform.matrix().getDouble(0,0); nit: space after the comma https://codereview.chromium.org/11567034/diff/8001/cc/layer_tree_host_common.... cc/layer_tree_host_common.cc:441: if (x_scale <= 0.0f || y_scale <= 0.0f) nit: "0.0", not "0.0f" since it's a double-double comparison
https://codereview.chromium.org/11567034/diff/8001/cc/layer_tree_host_common.cc File cc/layer_tree_host_common.cc (right): https://codereview.chromium.org/11567034/diff/8001/cc/layer_tree_host_common.... cc/layer_tree_host_common.cc:433: inline bool isPositiveScaleOrTranslation(const gfx::Transform& xform) This function is no longer used due to the reliance of axisAlignedWithRespectToParent in the recursive call. I'll remove it. On 2012/12/14 21:48:54, jamesr wrote: > is there a caller to this function? I can't find it. > > Can we share the logic that's common between this function and > TextureDrawQuad::PerformClipping() ? the two need to have the same return values > for correctness, and I suspect we'll want to make the clipping more general over > time, so if we can factor this into a shared function we'll only have one thing > to update rather than two things that we have to keep in sync with each other
Shawn or Dana should double check the transform use but I think this is right. Can you extend cc/layer_tree_host_common_unittest.cc to cover this optimization? There are enough non-obvious cases to check for that I think we need to have good test coverage. As I mentioned, I think it'd be much better to have the isPositive...() call somewhere that can be called by both texture_draw_quad and lth_common so we can make sure that they stay in perfect sync with each other since we do depend on it for correctness. https://codereview.chromium.org/11567034/diff/10001/cc/layer_tree_host_common.cc File cc/layer_tree_host_common.cc (right): https://codereview.chromium.org/11567034/diff/10001/cc/layer_tree_host_common... cc/layer_tree_host_common.cc:462: if (childLayer->drawsContent() && !childLayer->CanClipSelf() || multiple invocations of && and || merit some grouping parenthesis - compilers can follow precedence rules correctly, but it's harder for humans to do so quickly https://codereview.chromium.org/11567034/diff/10001/cc/layer_tree_host_common... cc/layer_tree_host_common.cc:466: canClipSelf = false; i would probably use braces around this block since it's a bit hard to tell the end of the if and the start of the actual block
In whatever unit tests you add, can you please make sure to test a clipping layer within a clipping layer? I havent fully reasoned through it, but I think we might have a correctness issue here. Suppose parent A and child B are both clipping; I think in the current code we are fundamentally relying on a renderSurface owned by parent A to correctly clip B's subtree. We probably need some extra logic for this case. https://codereview.chromium.org/11567034/diff/10001/cc/layer_tree_host_common.cc File cc/layer_tree_host_common.cc (right): https://codereview.chromium.org/11567034/diff/10001/cc/layer_tree_host_common... cc/layer_tree_host_common.cc:432: inline bool isPositiveScaleOrTranslation(const gfx::Transform& xform) Re: James' comment; I think a good place for this, for now, is MathUtil https://codereview.chromium.org/11567034/diff/10001/cc/layer_tree_host_common... cc/layer_tree_host_common.cc:466: canClipSelf = false; looking at this if-statement, there is a triple-meaning to "can clip self" that needs to be disambiguated. (1) The layer's accessor "CanClipSelf" perhaps should say "supportsSelfClipping". (2) The drawProperties can_clip_self actually seems like it should say "all_children_can_clip_themselves" (3) the actual "layer can clip itself" canClipSelf is implicit in this if-statement. I wonder if it would help readability to make that boolean explicit, just so the variable name exists to help people see the flow of logic. for example, something like this in code: bool thisLayerCanClipItself = <opposite of stuff currently inside your if statement> if (!thisLayerCanClipItself) allChildrenCanClipThemselves = false;
https://codereview.chromium.org/11567034/diff/10001/cc/draw_properties.h File cc/draw_properties.h (right): https://codereview.chromium.org/11567034/diff/10001/cc/draw_properties.h#newc... cc/draw_properties.h:81: int can_clip_self; Can you add a description comment for this please? (I have no idea what this means without reading the rest of the CL yet. Could this name be more descriptive? Clip is a super overloaded term in cc land.) https://codereview.chromium.org/11567034/diff/10001/cc/layer.h File cc/layer.h (right): https://codereview.chromium.org/11567034/diff/10001/cc/layer.h#newcode285 cc/layer.h:285: virtual bool CanClipSelf() const { return false; } We have accessors for draw properties that match their names. So can you make canClipSelf (lowercase first letter here..) be an accessor for m_drawProps.can_clip_self up with the other draw props accessors? Let's rename this function to something that doesn't collide with the draw property. Maybe something like allowClippingWithVertices or something more accurate and useful. https://codereview.chromium.org/11567034/diff/10001/cc/layer_impl.h File cc/layer_impl.h (right): https://codereview.chromium.org/11567034/diff/10001/cc/layer_impl.h#newcode284 cc/layer_impl.h:284: virtual bool CanClipSelf() const { return false; } same https://codereview.chromium.org/11567034/diff/10001/cc/layer_tree_host_common.cc File cc/layer_tree_host_common.cc (right): https://codereview.chromium.org/11567034/diff/10001/cc/layer_tree_host_common... cc/layer_tree_host_common.cc:432: inline bool isPositiveScaleOrTranslation(const gfx::Transform& xform) nit: call the variable "transform"? we don't do this elsewhere. https://codereview.chromium.org/11567034/diff/10001/cc/layer_tree_host_common... cc/layer_tree_host_common.cc:439: double y_scale = xform.matrix().getDouble(1, 1); What about z_scale? https://codereview.chromium.org/11567034/diff/10001/cc/layer_tree_host_common... cc/layer_tree_host_common.cc:453: bool sublayerXformPreventsClip = !isPositiveScaleOrTranslation(layer->sublayerTransform()); nit: "sublayerTransform..."
On 2012/12/15 00:02:17, danakj wrote: > https://codereview.chromium.org/11567034/diff/10001/cc/draw_properties.h > File cc/draw_properties.h (right): > > https://codereview.chromium.org/11567034/diff/10001/cc/draw_properties.h#newc... > cc/draw_properties.h:81: int can_clip_self; > Can you add a description comment for this please? (I have no idea what this > means without reading the rest of the CL yet. Could this name be more > descriptive? Clip is a super overloaded term in cc land.) > > https://codereview.chromium.org/11567034/diff/10001/cc/layer.h > File cc/layer.h (right): > > https://codereview.chromium.org/11567034/diff/10001/cc/layer.h#newcode285 > cc/layer.h:285: virtual bool CanClipSelf() const { return false; } > We have accessors for draw properties that match their names. So can you make > canClipSelf (lowercase first letter here..) be an accessor for > m_drawProps.can_clip_self up with the other draw props accessors? > > Let's rename this function to something that doesn't collide with the draw > property. Maybe something like allowClippingWithVertices or something more > accurate and useful. > > https://codereview.chromium.org/11567034/diff/10001/cc/layer_impl.h > File cc/layer_impl.h (right): > > https://codereview.chromium.org/11567034/diff/10001/cc/layer_impl.h#newcode284 > cc/layer_impl.h:284: virtual bool CanClipSelf() const { return false; } > same > > https://codereview.chromium.org/11567034/diff/10001/cc/layer_tree_host_common.cc > File cc/layer_tree_host_common.cc (right): > > https://codereview.chromium.org/11567034/diff/10001/cc/layer_tree_host_common... > cc/layer_tree_host_common.cc:432: inline bool isPositiveScaleOrTranslation(const > gfx::Transform& xform) > nit: call the variable "transform"? we don't do this elsewhere. > > https://codereview.chromium.org/11567034/diff/10001/cc/layer_tree_host_common... > cc/layer_tree_host_common.cc:439: double y_scale = xform.matrix().getDouble(1, > 1); > What about z_scale? > > https://codereview.chromium.org/11567034/diff/10001/cc/layer_tree_host_common... > cc/layer_tree_host_common.cc:453: bool sublayerXformPreventsClip = > !isPositiveScaleOrTranslation(layer->sublayerTransform()); > nit: "sublayerTransform..." Almost all of Dana's comment's were addressed in the last patch. I can add some better comments and rename the canClip to avoid collision. One thing to note here though is that this is all temporary stuff. I hope to make everything be able to clip itself in the not too distant future, which will eliminate pretty much this entire patch. In light of that I'm not eager to add fine polish to this.
On 2012/12/14 23:59:11, shawnsingh wrote: > In whatever unit tests you add, can you please make sure to test a clipping > layer within a clipping layer? > > I havent fully reasoned through it, but I think we might have a correctness > issue here. Suppose parent A and child B are both clipping; I think in the > current code we are fundamentally relying on a renderSurface owned by parent A > to correctly clip B's subtree. We probably need some extra logic for this case. > > https://codereview.chromium.org/11567034/diff/10001/cc/layer_tree_host_common.cc > File cc/layer_tree_host_common.cc (right): > > https://codereview.chromium.org/11567034/diff/10001/cc/layer_tree_host_common... > cc/layer_tree_host_common.cc:432: inline bool isPositiveScaleOrTranslation(const > gfx::Transform& xform) > Re: James' comment; I think a good place for this, for now, is MathUtil > > https://codereview.chromium.org/11567034/diff/10001/cc/layer_tree_host_common... > cc/layer_tree_host_common.cc:466: canClipSelf = false; > > looking at this if-statement, there is a triple-meaning to "can clip self" that > needs to be disambiguated. > (1) The layer's accessor "CanClipSelf" perhaps should say > "supportsSelfClipping". > (2) The drawProperties can_clip_self actually seems like it should say > "all_children_can_clip_themselves" > (3) the actual "layer can clip itself" canClipSelf is implicit in this > if-statement. I wonder if it would help readability to make that boolean > explicit, just so the variable name exists to help people see the flow of logic. > > for example, something like this in code: > > bool thisLayerCanClipItself = <opposite of stuff currently inside your if > statement> > if (!thisLayerCanClipItself) > allChildrenCanClipThemselves = false; The clipper checks the texturelayer's clip-rect which should have been correctly computed during some tree-walk. I can add a unit test but it wouldn't be related to this patch or any other code I've written so I'd probably put it in a new issue.
https://codereview.chromium.org/11567034/diff/1006/cc/draw_properties.h File cc/draw_properties.h (right): https://codereview.chromium.org/11567034/diff/1006/cc/draw_properties.h#newco... cc/draw_properties.h:81: int can_clip_self; bool?
nevermind, I solved it myself. I was thinking that, since we're now skipping renderSurfaces, that we may be missing the fact that it implicitly clips and does not propagate its clipRect to the subtree. However, that's not true... since we wouldn't be making the renderSurface in the first place, we would still be propagating the clipRect downwards. So i think that's not an issue. I'd still prefer the renaming, though. I think given that two of us reviewers saw it already, it's probably going to be a point of confusion for other readers of the code too, and it won't take much effort to do the renaming to mitigate that confusion before landing this =)
https://codereview.chromium.org/11567034/diff/1006/cc/draw_properties.h File cc/draw_properties.h (right): https://codereview.chromium.org/11567034/diff/1006/cc/draw_properties.h#newco... cc/draw_properties.h:81: int can_clip_self; Would still like a descriptive comment here to say what this variable is. https://codereview.chromium.org/11567034/diff/1006/cc/layer.h File cc/layer.h (right): https://codereview.chromium.org/11567034/diff/1006/cc/layer.h#newcode285 cc/layer.h:285: virtual bool canClipSelf() const { return false; } Even if this is meant to be short lived, we should not leave the code in a weird state. This name should be the accessor for m_drawProps.can_clip_self, and a different named thing should be the virtual method here. https://codereview.chromium.org/11567034/diff/1006/cc/layer_tree_host_common.cc File cc/layer_tree_host_common.cc (right): https://codereview.chromium.org/11567034/diff/1006/cc/layer_tree_host_common.... cc/layer_tree_host_common.cc:277: if (layerClipsSubtree(layer) && !axisAlignedWithRespectToParent && !layer->drawProperties().can_clip_self) Why doesn't a layer need to know that all layers in its entire subtree can each clip themselves to their respective parents in order to decide it doesn't need create and render the subtree into a render surface? Don't you need to check subtreeCanEachClipToParent? https://codereview.chromium.org/11567034/diff/1006/cc/layer_tree_host_common.... cc/layer_tree_host_common.cc:438: bool canClipSelf = true; Why isn't this initialized to the return for the current Layer::canClipSelf() function? Does that function actually mean allowClippingToParent? https://codereview.chromium.org/11567034/diff/1006/ui/gfx/transform.h File ui/gfx/transform.h (right): https://codereview.chromium.org/11567034/diff/1006/ui/gfx/transform.h#newcode82 ui/gfx/transform.h:82: bool IsPositiveScaleOrTranslation() const { Could you add a unit test in ui/gfx/transform_unittest.cc please?
The description says this CL "prevents proliferation of layers" but I'm not sure where any functionality is changing in this CL. So I'm having trouble seeing what the can_clip_self bit really means as well. AFAICT it seems to mean more specifically can_clip_self_to_parent? I'd like that name more since the current one is ambiguous.
On 2012/12/15 18:49:18, danakj wrote: > The description says this CL "prevents proliferation of layers" but I'm not sure > where any functionality is changing in this CL. So I'm having trouble seeing > what the can_clip_self bit really means as well. > > AFAICT it seems to mean more specifically can_clip_self_to_parent? I'd like that > name more since the current one is ambiguous. I agree, can_clip_self isn't a great name. I'm not sure that there is a good concise name that can be used for this variable. The property that it confers is: "All drawable layers in this subtree can clip themselves to an axis aligned clip region if one is defined. Specifically the subtree does not require scissoring or a render target to implement clipping." Does subtree_does_not_require_scissoring_for_correctness or some subset of that sound better Dana?
On 2012/12/17 23:16:47, whunt wrote: > On 2012/12/15 18:49:18, danakj wrote: > > The description says this CL "prevents proliferation of layers" but I'm not > sure > > where any functionality is changing in this CL. So I'm having trouble seeing > > what the can_clip_self bit really means as well. > > > > AFAICT it seems to mean more specifically can_clip_self_to_parent? I'd like > that > > name more since the current one is ambiguous. > > I agree, can_clip_self isn't a great name. I'm not sure that there is a good > concise name that can be used for this variable. The property that it confers > is: "All drawable layers in this subtree can clip themselves to an axis aligned > clip region if one is defined. Specifically the subtree does not require > scissoring or a render target to implement clipping." Does > subtree_does_not_require_scissoring_for_correctness or some subset of that sound > better Dana? I see, thanks for the full explanation. I think you can drop the "for_correctness" part and still have a nice name then, and give basically this as a comment on the variable in the draw props struct.
Thanks for putting up with all our comments. Here are my comments, mostly just nits, I think we really are finally reaching the final patch. https://codereview.chromium.org/11567034/diff/12002/cc/draw_properties.h File cc/draw_properties.h (right): https://codereview.chromium.org/11567034/diff/12002/cc/draw_properties.h#newc... cc/draw_properties.h:84: int does_not_require_scissoring; I feel like scissoring isn't the right word here. scissoring is one method of implementing the clip; the other method the code currently uses is to implicitly clip by having a renderSurface with limited bounds. So I feel like this variable name may get confusing. More comments about this variable name below. https://codereview.chromium.org/11567034/diff/12002/cc/layer_tree_host_common.cc File cc/layer_tree_host_common.cc (right): https://codereview.chromium.org/11567034/diff/12002/cc/layer_tree_host_common... cc/layer_tree_host_common.cc:242: nit: no need to add extra line here https://codereview.chromium.org/11567034/diff/12002/cc/layer_tree_host_common... cc/layer_tree_host_common.cc:440: bool sublayerXformPreventsClip = !layer->sublayerTransform().IsPositiveScaleOrTranslation(); like Dana, I also prefer Transform instead of Xform. I know we used it in gfx/transform_unittests but I think everywhere else our convention has been to spell out this word https://codereview.chromium.org/11567034/diff/12002/cc/layer_tree_host_common... cc/layer_tree_host_common.cc:450: !childLayer->drawProperties().does_not_require_scissoring || I feel like my proposed variable name in earlier comments got overlooked, but I really think it will help readability here. The point we want readers to realize is that this boolean tracks that information for all a layer's descendants, but not the layer itself. That's the key hint that makes this if-statement more readable, IMHO. Something like "descendants_can_clip_themselves". With that, the if-statement reads like: "check the layer, check it's descendants, check the transforms related to the childLayer" https://codereview.chromium.org/11567034/diff/12002/cc/layer_tree_host_common... File cc/layer_tree_host_common_unittest.cc (right): https://codereview.chromium.org/11567034/diff/12002/cc/layer_tree_host_common... cc/layer_tree_host_common_unittest.cc:354: Did you add these empty lines here with the intent of landing, or was it just vestigal stuff from local edits? Either way OK with me, but just FYI https://codereview.chromium.org/11567034/diff/12002/cc/layer_tree_host_common... cc/layer_tree_host_common_unittest.cc:408: gfx::Transform parentSublayerMatrix; This is unmodified; how about we just use identityMatrix below, and remove this declaration? https://codereview.chromium.org/11567034/diff/12002/cc/layer_tree_host_common... cc/layer_tree_host_common_unittest.cc:429: // Render surface should have been created now. We probably want to update this comment, should probably say something like "We expect that child should not create a render surface" https://codereview.chromium.org/11567034/diff/12002/cc/layer_tree_host_common... cc/layer_tree_host_common_unittest.cc:448: gfx::Transform parentSublayerMatrix; This is unmodified; how about we just use identityMatrix below, and remove this declaration? https://codereview.chromium.org/11567034/diff/12002/cc/layer_tree_host_common... cc/layer_tree_host_common_unittest.cc:469: // Render surface should have been created now. We probably want to update this comment, something like "This time we do expect a child surface to be created" https://codereview.chromium.org/11567034/diff/12002/cc/layer_tree_host_common... cc/layer_tree_host_common_unittest.cc:980: another empty line https://codereview.chromium.org/11567034/diff/12002/cc/texture_draw_quad.cc File cc/texture_draw_quad.cc (right): https://codereview.chromium.org/11567034/diff/12002/cc/texture_draw_quad.cc#n... cc/texture_draw_quad.cc:68: float x_scale = static_cast<float>(quadTransform().matrix().getDouble(0, 0)); don't forget to make these variables double as james and you had agreed =) looks like there are 4 lines that need that change https://codereview.chromium.org/11567034/diff/12002/ui/gfx/transform.h File ui/gfx/transform.h (right): https://codereview.chromium.org/11567034/diff/12002/ui/gfx/transform.h#newcode82 ui/gfx/transform.h:82: bool IsPositiveScaleOrTranslation() const { I would like to keep unit testing on gfx::transform very draconian and comprehensive. So we need unit tests that cover positive, negative, and zero scales for x, y, and z. If you want to defer making this unit test to a follow-up patch, make sure that's ok with danakj first and let's create a crbug assigned to one of us so that we do not forget it.
https://codereview.chromium.org/11567034/diff/12002/cc/layer_tree_host_common... File cc/layer_tree_host_common_unittest.cc (right): https://codereview.chromium.org/11567034/diff/12002/cc/layer_tree_host_common... cc/layer_tree_host_common_unittest.cc:354: Just trying to read the code, I'll remove them. On 2012/12/18 19:11:00, shawnsingh wrote: > Did you add these empty lines here with the intent of landing, or was it just > vestigal stuff from local edits? Either way OK with me, but just FYI https://codereview.chromium.org/11567034/diff/12002/cc/texture_draw_quad.cc File cc/texture_draw_quad.cc (right): https://codereview.chromium.org/11567034/diff/12002/cc/texture_draw_quad.cc#n... cc/texture_draw_quad.cc:68: float x_scale = static_cast<float>(quadTransform().matrix().getDouble(0, 0)); This is a slightly different piece of code than James and I were talking about. There need to be cast to floats because they're assigned to float values in RectF and Vector2dF. On 2012/12/18 19:11:00, shawnsingh wrote: > don't forget to make these variables double as james and you had agreed =) > looks like there are 4 lines that need that change https://codereview.chromium.org/11567034/diff/12002/ui/gfx/transform.h File ui/gfx/transform.h (right): https://codereview.chromium.org/11567034/diff/12002/ui/gfx/transform.h#newcode82 ui/gfx/transform.h:82: bool IsPositiveScaleOrTranslation() const { Assigning crbug to Shawn. On 2012/12/18 19:11:00, shawnsingh wrote: > I would like to keep unit testing on gfx::transform very draconian and > comprehensive. So we need unit tests that cover positive, negative, and zero > scales for x, y, and z. If you want to defer making this unit test to a > follow-up patch, make sure that's ok with danakj first and let's create a crbug > assigned to one of us so that we do not forget it.
LGTM+nits https://codereview.chromium.org/11567034/diff/21004/cc/draw_properties.h File cc/draw_properties.h (right): https://codereview.chromium.org/11567034/diff/21004/cc/draw_properties.h#newc... cc/draw_properties.h:84: int descendants_can_clip_selves; you meant bool here i think? https://codereview.chromium.org/11567034/diff/21004/cc/layer_tree_host_common... File cc/layer_tree_host_common_unittest.cc (right): https://codereview.chromium.org/11567034/diff/21004/cc/layer_tree_host_common... cc/layer_tree_host_common_unittest.cc:408: ASSERT_FALSE(root->renderSurface()); nit: you can use EXPECT_ for these tests. generally we only use ASSERT_ for something like checking the size of an array, to avoid crashing afterward. https://codereview.chromium.org/11567034/diff/21004/cc/layer_tree_host_common... cc/layer_tree_host_common_unittest.cc:418: setLayerPropertiesForTesting(root .get(), identityMatrix , identityMatrix , gfx::PointF( 0, 0), gfx::PointF(0, 0), gfx::Size( 1, 2), false); these extra spaces are funny, i'd remove them. lining up things across lines is generally bad and makes future diffs larger. https://codereview.chromium.org/11567034/diff/21004/cc/layer_tree_host_common... cc/layer_tree_host_common_unittest.cc:431: { if you made LayerCanClipSelf let you change the canClipSelf value, you could avoid all this 2nd copy of boilerplate code here, and just grandChild->setCanClipSelf(false), and run executeCalcDrawProps() again. https://codereview.chromium.org/11567034/diff/21004/cc/layer_tree_host_common... cc/layer_tree_host_common_unittest.cc:459: setLayerPropertiesForTesting(root .get(), identityMatrix , identityMatrix , gfx::PointF( 0, 0), gfx::PointF(0, 0), gfx::Size( 1, 2), false); same here https://codereview.chromium.org/11567034/diff/21004/ui/gfx/transform.h File ui/gfx/transform.h (right): https://codereview.chromium.org/11567034/diff/21004/ui/gfx/transform.h#newcode81 ui/gfx/transform.h:81: // Returns trus if the matrix is either a scale and/or translation nit: "true" misspelled. Mention the "IsPositive" part in the comment as well?
Sorry for being slow to review. I didn't realize you had updated the patch. If you publish with a "PTAL" I'll see that and know to look again, for the future.
https://codereview.chromium.org/11567034/diff/21004/cc/layer_tree_host_common... File cc/layer_tree_host_common_unittest.cc (right): https://codereview.chromium.org/11567034/diff/21004/cc/layer_tree_host_common... cc/layer_tree_host_common_unittest.cc:418: setLayerPropertiesForTesting(root .get(), identityMatrix , identityMatrix , gfx::PointF( 0, 0), gfx::PointF(0, 0), gfx::Size( 1, 2), false); I'm actually surprised about the push-back I get for block formatting here at Google. Block formatting makes the code easier to read (as a block) and makes it easier to spot errors/inconsistencies between lines. On top of that it improves programmer productivity by enabling block editing in good editors. I've never worked anywhere it wasn't considered good. I removed the spaces as requested but if I were to debug this code the first thing I would do is add them back so I could easily check for inconsistencies between lines. On 2012/12/19 22:46:56, danakj wrote: > these extra spaces are funny, i'd remove them. lining up things across lines is > generally bad and makes future diffs larger.
LGTM still. https://codereview.chromium.org/11567034/diff/34001/ui/gfx/transform.h File ui/gfx/transform.h (right): https://codereview.chromium.org/11567034/diff/34001/ui/gfx/transform.h#newcode81 ui/gfx/transform.h:81: // Returns true if the matrix is either a positive scale and/or a translation nit: missing a period on the end of the sentence.
CQ is trying da patch. Follow status at https://chromium-status.appspot.com/cq/[email protected]/11567034/34001
Failed to apply patch for cc/layer_tree_host_common.cc:
While running patch -p1 --forward --force --no-backup-if-mismatch;
patching file cc/layer_tree_host_common.cc
Hunk #1 FAILED at 274.
Hunk #2 succeeded at 468 (offset 33 lines).
1 out of 2 hunks FAILED -- saving rejects to file
cc/layer_tree_host_common.cc.rej
Patch: cc/layer_tree_host_common.cc
Index: cc/layer_tree_host_common.cc
diff --git a/cc/layer_tree_host_common.cc b/cc/layer_tree_host_common.cc
index
0a204ceb6914df96a5bdede2b6c8c9ee7e1c6915..273df6d51fcc0fb16116115748bdeda4b6a148ad
100644
--- a/cc/layer_tree_host_common.cc
+++ b/cc/layer_tree_host_common.cc
@@ -274,7 +274,7 @@ static bool subtreeShouldRenderToSeparateSurface(LayerType*
layer, bool axisAlig
return true;
// If the layer clips its descendants but it is not axis-aligned with
respect to its parent.
- if (layerClipsSubtree(layer) && !axisAlignedWithRespectToParent &&
numDescendantsThatDrawContent > 0)
+ if (layerClipsSubtree(layer) && !axisAlignedWithRespectToParent &&
!layer->drawProperties().descendants_can_clip_selves)
return true;
// If the layer has some translucency and does not have a preserves-3d
transform style.
@@ -435,15 +435,25 @@ template<typename LayerType>
static void preCalculateMetaInformation(LayerType* layer)
{
int numDescendantsThatDrawContent = 0;
+ bool descendantsCanClipSelves = true;
+ bool sublayerTransformPreventsClip =
!layer->sublayerTransform().IsPositiveScaleOrTranslation();
for (size_t i = 0; i < layer->children().size(); ++i) {
LayerType* childLayer = layer->children()[i];
preCalculateMetaInformation<LayerType>(childLayer);
+
numDescendantsThatDrawContent += childLayer->drawsContent() ? 1 : 0;
numDescendantsThatDrawContent +=
childLayer->drawProperties().num_descendants_that_draw_content;
+
+ if ((childLayer->drawsContent() && !childLayer->canClipSelf()) ||
+ !childLayer->drawProperties().descendants_can_clip_selves ||
+ sublayerTransformPreventsClip ||
+ !childLayer->transform().IsPositiveScaleOrTranslation())
+ descendantsCanClipSelves = false;
}
layer->drawProperties().num_descendants_that_draw_content =
numDescendantsThatDrawContent;
+ layer->drawProperties().descendants_can_clip_selves =
descendantsCanClipSelves;
}
// Recursively walks the layer tree starting at the given node and computes all
the
CQ is trying da patch. Follow status at https://chromium-status.appspot.com/cq/[email protected]/11567034/38003
Failed to apply patch for cc/layer_tree_host_common_unittest.cc:
While running patch -p1 --forward --force --no-backup-if-mismatch;
patching file cc/layer_tree_host_common_unittest.cc
Hunk #2 FAILED at 349.
1 out of 3 hunks FAILED -- saving rejects to file
cc/layer_tree_host_common_unittest.cc.rej
Patch: cc/layer_tree_host_common_unittest.cc
Index: cc/layer_tree_host_common_unittest.cc
diff --git a/cc/layer_tree_host_common_unittest.cc
b/cc/layer_tree_host_common_unittest.cc
index
25ff83d610eb2f7dddc6f5c8dc728facc1af81a7..17e105fbfaacfeadc170e42b26f3758718653c9f
100644
--- a/cc/layer_tree_host_common_unittest.cc
+++ b/cc/layer_tree_host_common_unittest.cc
@@ -111,6 +111,22 @@ private:
}
};
+class LayerCanClipSelf : public Layer {
+public:
+ LayerCanClipSelf()
+ : Layer()
+ {
+ }
+
+ virtual bool drawsContent() const OVERRIDE { return true; }
+ virtual bool canClipSelf() const OVERRIDE { return true; }
+
+private:
+ virtual ~LayerCanClipSelf()
+ {
+ }
+};
+
class MockContentLayerClient : public ContentLayerClient {
public:
MockContentLayerClient() { }
@@ -333,11 +349,12 @@ TEST(LayerTreeHostCommonTest,
verifyTransformsForSingleRenderSurface)
parentTranslationToAnchor.Translate(25, 30);
gfx::Transform parentSublayerMatrix;
parentSublayerMatrix.Scale3d(0.9, 1, 3.3);
+
gfx::Transform parentTranslationToCenter;
parentTranslationToCenter.Translate(50, 60);
gfx::Transform parentCompositeTransform = parentTranslationToAnchor *
parentLayerTransform * MathUtil::inverse(parentTranslationToAnchor)
* parentTranslationToCenter * parentSublayerMatrix *
MathUtil::inverse(parentTranslationToCenter);
- gfx::Vector2dF parentCompositeScale =
MathUtil::computeTransform2dScaleComponents(parentCompositeTransform, 1.f);
+ gfx::Vector2dF parentCompositeScale =
MathUtil::computeTransform2dScaleComponents(parentCompositeTransform, 1.0f);
gfx::Transform surfaceSublayerTransform;
surfaceSublayerTransform.Scale(parentCompositeScale.x(),
parentCompositeScale.y());
gfx::Transform surfaceSublayerCompositeTransform = parentCompositeTransform
* MathUtil::inverse(surfaceSublayerTransform);
@@ -367,6 +384,91 @@ TEST(LayerTreeHostCommonTest,
verifyTransformsForSingleRenderSurface)
EXPECT_TRANSFORMATION_MATRIX_EQ(surfaceSublayerCompositeTransform,
child->renderTarget()->renderSurface()->screenSpaceTransform());
}
+TEST(LayerTreeHostCommonTest,
verifySeparateRenderTargetRequirementWithClipping)
+{
+ scoped_refptr<Layer> root = Layer::create();
+ scoped_refptr<Layer> parent = Layer::create();
+ scoped_refptr<Layer> child = Layer::create();
+ scoped_refptr<Layer> grandChild = make_scoped_refptr(new
LayerCanClipSelf());
+ root->addChild(parent);
+ parent->addChild(child);
+ child->addChild(grandChild);
+ parent->setMasksToBounds(true);
+ child->setMasksToBounds(true);
+
+ gfx::Transform identityMatrix;
+ gfx::Transform parentLayerTransform;
+ gfx::Transform parentSublayerMatrix;
+ gfx::Transform childLayerMatrix;
+
+ // No render surface should exist yet.
+ EXPECT_FALSE(root->renderSurface());
+ EXPECT_FALSE(parent->renderSurface());
+ EXPECT_FALSE(child->renderSurface());
+ EXPECT_FALSE(grandChild->renderSurface());
+
+ // One-time setup of root layer
+ parentLayerTransform.Scale3d(1, 0.9, 1);
+ parentSublayerMatrix.Scale3d(0.9, 1, 3.3);
+ childLayerMatrix.Rotate(20);
+
+ setLayerPropertiesForTesting(root.get(), identityMatrix, identityMatrix,
gfx::PointF(0, 0), gfx::PointF(0, 0), gfx::Size(1, 2), false);
+ setLayerPropertiesForTesting(parent.get(), parentLayerTransform,
parentSublayerMatrix, gfx::PointF(0.25, 0.25), gfx::PointF(0, 0), gfx::Size(100,
120), false);
+ setLayerPropertiesForTesting(child.get(), childLayerMatrix, identityMatrix,
gfx::PointF(0, 0), gfx::PointF(0, 0), gfx::Size(16, 18), false);
+ setLayerPropertiesForTesting(grandChild.get(), identityMatrix,
identityMatrix, gfx::PointF(0, 0), gfx::PointF(0, 0), gfx::Size(8, 10), false);
+
+ executeCalculateDrawProperties(root.get());
+
+ // Render surfaces should have been created according to clipping rules now
(grandchild can clip self).
+ EXPECT_TRUE(root->renderSurface());
+ EXPECT_FALSE(parent->renderSurface());
+ EXPECT_FALSE(child->renderSurface());
+ EXPECT_FALSE(grandChild->renderSurface());
+}
+
+TEST(LayerTreeHostCommonTest,
verifySeparateRenderTargetRequirementWithoutClipping)
+{
+ scoped_refptr<Layer> root = Layer::create();
+ scoped_refptr<Layer> parent = Layer::create();
+ scoped_refptr<Layer> child = Layer::create();
+ // This layer cannot clip itself, a feature we are testing here.
+ scoped_refptr<Layer> grandChild = make_scoped_refptr(new
LayerWithForcedDrawsContent());
+ root->addChild(parent);
+ parent->addChild(child);
+ child->addChild(grandChild);
+ parent->setMasksToBounds(true);
+ child->setMasksToBounds(true);
+
+ gfx::Transform identityMatrix;
+ gfx::Transform parentLayerTransform;
+ gfx::Transform parentSublayerMatrix;
+ gfx::Transform childLayerMatrix;
+
+ // No render surface should exist yet.
+ EXPECT_FALSE(root->renderSurface());
+ EXPECT_FALSE(parent->renderSurface());
+ EXPECT_FALSE(child->renderSurface());
+ EXPECT_FALSE(grandChild->renderSurface());
+
+ // One-time setup of root layer
+ parentLayerTransform.Scale3d(1, 0.9, 1);
+ parentSublayerMatrix.Scale3d(0.9, 1, 3.3);
+ childLayerMatrix.Rotate(20);
+
+ setLayerPropertiesForTesting(root.get(), identityMatrix, identityMatrix,
gfx::PointF(0, 0), gfx::PointF(0, 0), gfx::Size(1, 2), false);
+ setLayerPropertiesForTesting(parent.get(), parentLayerTransform,
parentSublayerMatrix, gfx::PointF(0.25, 0.25), gfx::PointF(0, 0), gfx::Size(100,
120), false);
+ setLayerPropertiesForTesting(child.get(), childLayerMatrix, identityMatrix,
gfx::PointF(0, 0), gfx::PointF(0, 0), gfx::Size(16, 18), false);
+ setLayerPropertiesForTesting(grandChild.get(), identityMatrix,
identityMatrix, gfx::PointF(0, 0), gfx::PointF(0, 0), gfx::Size(8, 10), false);
+
+ executeCalculateDrawProperties(root.get());
+
+ // Render surfaces should have been created according to clipping rules now
(grandchild can't clip self).
+ EXPECT_TRUE(root->renderSurface());
+ EXPECT_FALSE(parent->renderSurface());
+ EXPECT_TRUE(child->renderSurface());
+ EXPECT_FALSE(grandChild->renderSurface());
+}
+
TEST(LayerTreeHostCommonTest, verifyTransformsForReplica)
{
scoped_refptr<Layer> root = Layer::create();
CQ is trying da patch. Follow status at https://chromium-status.appspot.com/cq/[email protected]/11567034/34002
Message was sent while issue was closed.
Change committed as 175919 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
