Tab Switching performance seriously slow

[mysterydiner]

REQUIRED INFORMATION

Ext version tested:

• Sencha Touch 2 (PR1 & PR2)

Browser versions tested against:

• Chrome Latest
• IOS 5 Ipad

Description:

• Tab Switching is seriously slow in supplied test case. Even on my I7 monster workstation running chrome on windows 7 this takes around 5 seconds. IOS 5 even longer

Steps to reproduce the problem:

RUN THE SUPPLIED TEST CASE. Switch between two tabs - monitor performance

The result that was expected:

• fast response

The result that occurs instead:

• browser goes mad doing layout

Test Case:

test.zip

should run on any server or locally from file system - no back end dependancies.
Change script urls in index-nocache.html to point to valid sencha touch 2 installation.




HELPFUL INFORMATIONScreenshot or Video:

• attached

See this URL for live test case: http://Debugging already done:

• none

Possible fix:

• not provided

Additional CSS used:

• only default ext-all.css

Operating System:

• IOS 5 0 IPAD 1 & 2_______
• Windows 7 Pro

[mitchellsimoens]

On a mobile device I don't expect a layout like this to take a while... you have quite a lot going on. Layouts aren't done by JavaScript, it's done using CSS so the actual layout is done by the browser. All we do is create the <div> structure.

[mysterydiner]

Michael, there's definitely something wrong here. on my vey very fast i7 desktop running chrome this takes five seconds. more like 15 seconds on an iPad 2 - even with animation disabled!

I don't feel this is fair to blame this on CSS out of hand without actually looking into it detail. there's only about 40 objects on the page. it's not like its a massive page.

if you want to make the jump to a feasible Platform for tablet dev as well as phone your going to have to deal with cases like this I'm afraid. quite frankly the performance on this example is very very poor and it's embarrassing me in front of a client.

sorry if I sound a little hot under the collar but I was quite taken a back by the dismissive ness of the reply.

Best Regards Tom

[mitchellsimoens]

Not to piss you off or anything, we are still in PR stages with PR3 coming next week. So not everything is flushed out

[mysterydiner]

Thanks Michael,
Totally understand that this is a tech preview and that we're all on a bit of a journey.
Just to reassure you, apart from this one issue my ipad app is kicking ass on PR2.
It's not due to go live till feb so I have the luxury of being able to surf on the bleeding edge for a while.
Hopefully the risk will pay off.

I'm under a little bit of pressure from the project that some of the app feels clunky because of this tab switching issue so all I need from you guys is to accept the bug report as an issue that will be dealt with.

also I'm a noob as far as the intricacies of the website layout engine are concerned. so any pointers on how to optimise this layout to help the layout engine would be very valuable even if it means some compromises on my part. I've watched the perfomance opts videos and tried to apply that learning to this situation without any success.

I'm sure you can appreciate that 15 seconds of layout processing on a fast ipad 2 for even a complex layout is excessive. not to mention that this brings my very very fast desktop to its knees for 5 seconds.

Also popping up a loading mask for up to 4 seconds would be acceptable for us in production but I cannot seem to do this in the show event of the panel. Maybe I need to attach to some other events?

Regards

Tom

[Jamie Avins]

Thank you for the example, we'll check it out.

[mysterydiner]

BUMP!.......
FYI Performance is still as poor with PR3 for this test/bug.

[rdougan]

Unfortunately because you are using so many layouts, components, and elements on one page, it just brings the browser to a halt. EVen if you were to create this in a native application, you would come across a similar issue.

ST uses 100% CSS for all of its layout, so there are two limitations of browsers we cannot overcome:

1. Using so many CSS flex boxes (we use this for hbox and vbox layouts) will easily slow down even modern browsers (as you found out). I counted ~17 in your application, which even in a complicated application or website, is a lot (for one `page`).
2. The more components you use, the higher the DOM and memory usage is. We've put a huge amount of effort into ST2 to make sure that component instantiation is as fast as possible out of the box, so developers don't have to worry about it so much. But, you have to remember that each component you use has a template, and all those DOM nodes need to be added into the document body. I counted ~70 components on your "View Case" card, which along with the amount of layouts is.. incredible!

So if there isn't much we can do about it, how do you improve performance?

1. Try and cut down on the number of components per view; and by view, I mean, visible at any one time. This will drastically help.
2. If you cannot do the above, or at least can't do it much, you will need to start writing your own custom components. From looking at your example, one which would help would be for the checkbox panels (where you are inserting 8 checkbook fields in one panel). In this case, you could create a custom component which has a custom template which includes all 8 `<input type="checkbox" />` fields. That would mean that this block of elements would be all inserted at once into the DOM. It would also mean you would cut down on all the extra DOM needed for all those layouts in just that one panel.
3. And like you mentioned, some kind of mask. You could do this by adding a mask to the tab panel before you change the active card. I'm not sure if the events are working for this in PR3, but you'd listen to the `activeitemchange` event.

Hopefully this will help you on your quest for smoothness.

[mysterydiner]

Thanks for the feedback. Very helpful and constructive.
I've done as suggested and it has solved my problem.
FYI it seems to be the checkboxe compenents that really exacerbate this problem.
It may be well worth looking into the performance of these.
I have copied most of the styles from the sencha checkbox components in my custom component and removed some extraneous flex attributes and the performance is much better.

Thanks again.