Every panel transition in the music app is extremely janky (quite often no frames at all, otherwise a handful of frames) - as opposed to the smooth transitions you can observe in the Settings app.

I have talked to Dominic, he said he's now working on this and the reason of janky is because it's translating a div contains a bunch of child divs and the size is much larger than screen.

(In reply to Ting-Yu Chou [:ting] from comment #1) > I have talked to Dominic, he said he's now working on this and the reason of > janky is because it's translating a div contains a bunch of child divs and > the size is much larger than screen. In which case, adding overflow:hidden during the transition sounds like an easy fix :)

Profile: http://people.mozilla.org/~bgirard/cleopatra/#report=8edce603b6b2b959e4362f8a72177525757426b8 Captured on a Nexus5 while selecting "Highest rated" from "Playlist" view with command: $ ./profile.sh start -p b2g -t Compositor,GeckoMain -f restyle,js,stackwalk; ./profile.sh start -p Music -f restyle,js,stackwalk; sleep 5; ./profile.sh capture

(In reply to Chris Lord [:cwiiis] from comment #2) > (In reply to Ting-Yu Chou [:ting] from comment #1) > > I have talked to Dominic, he said he's now working on this and the reason of > > janky is because it's translating a div contains a bunch of child divs and > > the size is much larger than screen. > > In which case, adding overflow:hidden during the transition sounds like an > easy fix :) I am not sure how to do this. Music has 4 views (tiles, list, sublist, player) lie horizontally, and when mode changes it translates the container div [1]. But for Settings, only previous and current panels are affected [2]. I tried to add "overflow: hidden" to the rule of #views, but it will show nothing when switch to different view. [1] http://lxr.mozilla.org/gaia/source/apps/music/style/music.css#251 [2] http://mxr.mozilla.org/gaia/source/apps/settings/style/settings.css#69

The music refactoring work in bug 1055049 should fix this, I am changing the panel transitions base on the proposal in [1]. [1] https://docs.google.com/presentation/d/1faI_oNwk309A6X6oGrk0DXaTssa5Jh2EE1FqCiKOIN0/

Dominic just demo me his latest work to me, and it's quite smooth. But he noticed me even without bug 1055049's patch, if the panel going to show does not overflow the screen height, then the transition will go smoother. The strange thing is there's already a "overflow-y:hidden" for #views-sublist, I am afraid this is a gecko bug, will double check.

(In reply to Ting-Yu Chou [:ting] from comment #6) > But he noticed me even without bug 1055049's patch, if the panel going to > show does not overflow the screen height, then the transition will go > smoother. The strange thing is there's already a "overflow-y:hidden" for > #views-sublist, I am afraid this is a gecko bug, will double check. It is not. "overflow-y: hidden" applies to #views-sublist but not #views-scrollable-sublist-anchor. When moves into sublist view, all the database entries will be enumerated and appendChild to #views-sublist-anchor, and the work of ClientTiledPaintedLayer::RenderLayer() will depend on the numbers. Chris is right, a simple patch to set #views-scrollable-sublist-anchor overflowY hidden when transistion start and set it back to auto after transisionend can make it smoother.

Thanks Ting-Yu and Chris, I have fixed this in part of bug 1055049, it's on master and feel free to try it :) I am closing this bug since it's fixed, but if you need this bug to trace some gecko issue, just re-open it.