Overdraw about android-menudrawer HOT 9 CLOSED

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.

from android-menudrawer.

@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 View.GONE when fully closed.

from android-menudrawer.

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.

from android-menudrawer.

Can we do something with calling setWillNotDraw when fully closed?

from android-menudrawer.

I don't think so. I wrap the menu layout in a framelayout, which doesn't do
any drawing. setWillNotDraw doesn't propagate to child views.
I'll have to investigate what exactly happens when visibility is toggled
before deciding what to do, but I don't really think we want to cause a
redraw of the menu (which will have to happen when its shown again).
Keeping the hardware layer as-is, but off screen, might be faster.
On Dec 6, 2012 12:04 AM, "Jake Wharton" [email protected] wrote:

Can we do something with calling setWillNotDraw when fully closed?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/44#issuecomment-11065325.

from android-menudrawer.

Custom FrameLayout that doesn't dispatch drawing to children when drawer is closed?

from android-menudrawer.

Is onDraw called at all unless the menu view is invalidated? I think this
might be all in the GPU.
On Dec 6, 2012 12:46 AM, "Jake Wharton" [email protected] wrote:

Custom FrameLayout that doesn't dispatch drawing to children when drawer
is closed?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/44#issuecomment-11066743.

from android-menudrawer.

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.

from android-menudrawer.

Nice work. Thank you Simon

from android-menudrawer.