-
Notifications
You must be signed in to change notification settings - Fork 817
LAYER_TYPE_HARDWARE improve the performance #67
Comments
Curious, what was "happyView" here? If happyView is complex, that would make sense, since every draw operation in the animation would be just rendering a simple layer rather than executing the view's entire display list. But if happyView is simple, it's probably not going to win you anything. I think it'd actually just occupy more memory unnecessarily to hold that hardware layer. I've seen OOM errors go down just by trying to limit how many views were set as hardware layer types at a given time. I wouldn't want people to go overboard in the other direction. I'm not sure where the line is between "simple" and "complex", though... But yeah, might be nice to have a note about this... maybe also handy to have a link to a resource about Android animation perf in general, so people can be sure they're getting the best out of Rebound. |
HappyView is an beautiful view that makes the user more happy. :) |
@richkzad I don't have noticed no one OOM yet. |
If you're only turning on the hardware layer during the spring animation, OOMs much less likely to happen. I'm talking more about if you keep multiple views as hardware layers. It also depends on the device. Using the hardware layer is only going to help you out if the contents inside that view are not changing. In the Inertia Ball example from rebound-android-playground, the view is going to continuously redraw itself while the spring is active. So I believe the hardware layer will not benefit you at all, and just use extra memory. The hardware layer is useful if you want to, say, scale a large ViewGroup or View with complex draw instructions whose contents aren't changing. Then, Android can just continuously redraw that single hardware layer rather than process all the individual draw instructions that make up that view. |
@richkzad |
@richkzad What do you think about it? private ComplexSpringListener complexSpringListener = new ComplexSpringListener(View[]) {
@Override public void onSpringActivate(Spring spring, View[] views) {
super.onSpringActivate(spring); //attach the LayerType
}
@Override public void onSpringUpdate(Spring spring, View[] views) {
super.onSpringUpdate(spring);
// do complex transitions with the view, get the view with views[n].
}
@Override public void onSpringAtRest(Spring spring, View[] views) {
super.onSpringAtRest(spring); //detach the LayerType
}
}; |
You could also achieve this by adding a second listener to your spring. The listener's sole, generic purpose could be setting a view to a hardware layer type during the spring, like: happySpring
.addListener(new HappySpringListener())
.addListener(new HardwareLayerSpringListener(happyView)); With this style, this you could compose several behaviors into your spring without a mess of inheritance or worrying about forgetting to call through to the supers. |
@richkzad Cool idea man! |
@willbailey What do you think about this new feature? |
I think it's a pretty good idea. If you want to send a PR to add it I'll take a look. Otherwise I'll try to work on it sometime soon. I'd make the HardwareLayerSpringListener accept var args of View... |
@willbailey Rebound-Core doesn't have the View class from android. Can I implement this feature at Rebound-Android? |
Second these slides, add this property to the view will increase the performance of the animations. And did!
I've an complex animation on my application, a little bit slow. After I add this property, the animation runs at 60fps smoothly.
Usage:
Or, we can use ViewCompat to support API 10 using:
We can advise the developers to don't forget this point.
The text was updated successfully, but these errors were encountered: