Fixed
Status Update
No update yet.
Comments
ap...@google.com
I know that there is an API council request to change Modifier.drawLayer to Modifier.graphicsLayer` thus dropping the "draw" prefix to the modifier. I think it might be reasonable to rename the following to match the naming of the fields within the layer API:
Introduce the following:
Modifier.drawOpacity -> Modifier.alpha
Modifier.scale,
Modifier.rotateX,
Modifier.rotateY,
Modifier.rotate (maybe rotateZ but maybe drop the Z to keep it simple?)
Modifier.translate
I think it is reasonable to have both Modifier.offset as well as translate with the documentation indicating that translate is more effective for animated use cases. The only concern I have is if we can somehow detect several of these modifiers in a chain would be able to effectively squash them into a single layer, (ex: Modifier.alpha(0.5f).scale(2f).rotate(45) etc.). What do you think?
wa...@gmail.com
1) you forgot to mention:
Modifier.drawShadow -> Modifier.shadow
2) I think for scale we can both overloads like
Modifier.scale(scaleX: Float, scaleY: Float)
Modifier.scale(scale: Float) = scale(scale, scale)
3) can we do similar thing for rotation? in simple cases you only want to rotate x and y, right?
Modifier.rotation(rotationX: Float, rotationY: Float, rotationZ: Float)
Modifier.rotation(rotation: Float) = rotation(rotation, rotation, 0)
4) and please, lets not add Modifier.translate() just yet. I am ok with this being available as more low level api Modifier.drawLayer() where we have more options, but not something so easy discoverable. in the doc we agreed that it could be useful to keep it for some complex cases. I am strongly convinced we shoudn't have both Modifier.offsetPx() and Modifier.translation()
5) so the decision to rename to graphicLayer() is final? I have a cl which will be affected by that:https://android-review.googlesource.com/c/platform/frameworks/support/+/1496274 . Should I already use new name GraphicLayerScope there?
Modifier.drawShadow -> Modifier.shadow
2) I think for scale we can both overloads like
Modifier.scale(scaleX: Float, scaleY: Float)
Modifier.scale(scale: Float) = scale(scale, scale)
3) can we do similar thing for rotation? in simple cases you only want to rotate x and y, right?
Modifier.rotation(rotationX: Float, rotationY: Float, rotationZ: Float)
Modifier.rotation(rotation: Float) = rotation(rotation, rotation, 0)
4) and please, lets not add Modifier.translate() just yet. I am ok with this being available as more low level api Modifier.drawLayer() where we have more options, but not something so easy discoverable. in the doc we agreed that it could be useful to keep it for some complex cases. I am strongly convinced we shoudn't have both Modifier.offsetPx() and Modifier.translation()
5) so the decision to rename to graphicLayer() is final? I have a cl which will be affected by that:
jo...@gmail.com
Comment has been deleted.
jo...@gmail.com
Comment has been deleted.
jo...@gmail.com
Comment has been deleted.
jo...@gmail.com
2,3. will leave the decision on scale/rotation on you as you have more context here.
4. "full layout pass" sounds scary but in fact we only need to re-invoke affected layout block(s), even without remeasuring. so it is cheap already. as I mentioned in the doc previously we do relayout for scrolling of the scrolling containers which is an operation of the same complexity as a translation animation as I would say. instead of providing two mechanisms for offsetting the component we just need one which is performant. if you have ideas how to do even less work in simple relayouts lets optimize it instead of overcomplicating the public api.
5. Yes, I saw this feedback. My question was mostly about when are you going to rename/as there is no reason to introduce DrawLayerScope to rename it to GraphicLayerScope right after
4. "full layout pass" sounds scary but in fact we only need to re-invoke affected layout block(s), even without remeasuring. so it is cheap already. as I mentioned in the doc previously we do relayout for scrolling of the scrolling containers which is an operation of the same complexity as a translation animation as I would say. instead of providing two mechanisms for offsetting the component we just need one which is performant. if you have ideas how to do even less work in simple relayouts lets optimize it instead of overcomplicating the public api.
5. Yes, I saw this feedback. My question was mostly about when are you going to rename/as there is no reason to introduce DrawLayerScope to rename it to GraphicLayerScope right after
Description
PxBounds should be removed and Rect should be used everywhere PxBounds is used.