Hi all,
I'm building a Phone gap application running on iPad 3 using Kendo Mobile.
I currently have around 8 views on 1 html. 2 of the views have Kendo DataViz.
Transition across views are set to use slide.
Kendo Mobile controls are defined using data-* markups (instead of programmatically from javascript).
Helper classes, etc. are defined as javascript classes using closures.
There are minimal logic in javascript other than calling webservices with jquery and updating the UI with jquery selector (not MVVM).
As you see above, the app is very simple & small in nature. Yet, I'm having performance issues:
I'm building a Phone gap application running on iPad 3 using Kendo Mobile.
I currently have around 8 views on 1 html. 2 of the views have Kendo DataViz.
Transition across views are set to use slide.
Kendo Mobile controls are defined using data-* markups (instead of programmatically from javascript).
Helper classes, etc. are defined as javascript classes using closures.
There are minimal logic in javascript other than calling webservices with jquery and updating the UI with jquery selector (not MVVM).
As you see above, the app is very simple & small in nature. Yet, I'm having performance issues:
- activating Kendo Mobile button requires longer tap. quick tap will trigger button "on down" animation however do not trigger the view redirection (redirection is done using href, not application.navigate)
- sliding between view is notably sluggish. for 30-50ms I can see the background of the view rendering on the background. so for that moment, there's a white vertical stripe panning across left to right
Do you see any obvious flaw in the approach above that may cause performance issues?
- does splitting views across html help performance?
- should I be relying on other view transitions that inherintly lighter?
- should I define the Kendo controls programmatically rather using data-*? is there a penalty for having to rely on Kendo scanning the whole dom for data-* attributes?
- is there specific best practices for managing memory in javascript in relation to Kendo?
Thanks
1 Answer, 1 is accepted
0
Hi Ronald,
Unfortunately we are still waiting for our testing iPad 3, so we can't currently say if the slow background rendering is due to a bug in Kendo UI Mobile or an iPad 3 UIWebView limitation of some kind. Can you test if the said issues can be reproduced on an iPad 2? If so, can you send a sample page where we can reproduce the issues you have.
About the other performance questions you have:
1. Splitting views would probably help during the initial load, as less views will be initialized. However, there's a trade off - when you open the view for the first time, it will be slower to load and you may also get a loading message
2. Every transition is limited by the max texture size of the video chip in the device - if the max texture size is smaller than the resolution, you may face tearing and other performance problems regardless of the transition type. There were no problems with that on previous Apple devices, however iPad 3 introduced 4x times the previous resolution, while the video chip remained the same (though with more cores). I'm getting reports that the max texture size there was upped to 4096x4096, however without testing it, we can't commit full support.
3. The performance penalty from the declarative initialization is negligible to none. For now, I would not recommend optimizing that.
4. There isn't anything kendo specific regarding memory management. In your case, I believe that the memory usage is not the culprit. Sounds more like a rendering CPU/GPU bottleneck.
If you discover anything more specific, please do not hesitate to contact us again. We will do our best to help.
Regards,
Petyo
the Telerik team
Unfortunately we are still waiting for our testing iPad 3, so we can't currently say if the slow background rendering is due to a bug in Kendo UI Mobile or an iPad 3 UIWebView limitation of some kind. Can you test if the said issues can be reproduced on an iPad 2? If so, can you send a sample page where we can reproduce the issues you have.
About the other performance questions you have:
1. Splitting views would probably help during the initial load, as less views will be initialized. However, there's a trade off - when you open the view for the first time, it will be slower to load and you may also get a loading message
2. Every transition is limited by the max texture size of the video chip in the device - if the max texture size is smaller than the resolution, you may face tearing and other performance problems regardless of the transition type. There were no problems with that on previous Apple devices, however iPad 3 introduced 4x times the previous resolution, while the video chip remained the same (though with more cores). I'm getting reports that the max texture size there was upped to 4096x4096, however without testing it, we can't commit full support.
3. The performance penalty from the declarative initialization is negligible to none. For now, I would not recommend optimizing that.
4. There isn't anything kendo specific regarding memory management. In your case, I believe that the memory usage is not the culprit. Sounds more like a rendering CPU/GPU bottleneck.
If you discover anything more specific, please do not hesitate to contact us again. We will do our best to help.
Regards,
Petyo
the Telerik team
Join us on our journey to create the world's most complete HTML 5 UI Framework - download Kendo UI now!