-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Overdraw #44
Comments
I am not an expert in optimization but in the article the issue where about views never displayed because they are covered by another view. In the case of this lib, to not have 2 layers you would have to destroy the menu each time it s hided, right ? So it means you would have to recreate the menu each time the user wants to use it. It takes time. So no more butter experience! The hided view here is useful, not like a view you will never see. Even if sometimes it is under another one. |
@SimonVT and myself talked about this briefly on IRC. Can't remember where we came down but I think it has something to do with the fact that the library uses hardware layers. Probably still should be setting the drawer to |
I'm a bit concerned about what will happen with the hardware layer if the visibility is set to gone. If its destroyed, it can take something like 50-100ms to recreate once it is shown again, which is not acceptable. If that is the case, simply moving the view off screen might be a better solution. |
Can we do something with calling |
I don't think so. I wrap the menu layout in a framelayout, which doesn't do
|
Custom |
Is onDraw called at all unless the menu view is invalidated? I think this
|
Should be fixed. The selected solution was to move the menu off screen when drawer is closed, and hardware layers are used, since e.g. toggling visibility caused noticeable delay the first time the drawer was opened. |
Nice work. Thank you Simon |
A new developer option in JellyBean 4.2 allows you to show GPU overdraw (you've probably seen it already at http://www.curious-creature.org/2012/12/01/android-performance-case-study).
With this option enabled you can see that the sliding menu is still being drawn behind the content view even when the sliding drawer is shut.
This will have a negative performance impact on any activity that uses this.
The text was updated successfully, but these errors were encountered: