09-22-2011 07:45 AM
Unfortunately the scrolling lag inherent in the OS5, 6, 7 simulators and devices is much more noticeable than the equivalent action in a Java-based app. All the app is doing is changing the colour of the P element text in response to the touchpad, but it feels laggy and sluggish compared the snappy native apps.
I've eagerly followed Webworks since it was called Widgets, hoping one day to be able to utilize web development across different platforms, but I can't really imagine any client putting up with the sluggishness of a Webworks scrolling list and therefore will have to look at other development avenues.
Has anyone else experienced similar issues? I searched the forum and there are many posts about the JS/UI thread deadlock but none about the general sluggish feel of focus-based Webworks apps.
Solved! Go to Solution.
09-23-2011 07:54 AM
The work is underway and you can see it on the roadmap:
We were trying to get these changes completed in time for DevCon but with all of the memory fixes we had to bump it into a follow up release
There is also a highly experimental branch in my github repo where (if you're up to it) you can try out some of the prototype changes. From my experimentation, this makes scrolling as fast as native on BB6 and BB7 devices.
The code in my Repo is HIGHLY experimental and isn't meant for mainsteam use. But you can check it out so you can see how much of an improvement is made.
We know it's a priority and we are working on it.
10-06-2011 04:44 AM
Hi Tim -
10-06-2011 08:27 AM
I don't really have a date yet for the updates.. everyone has been heads down on the v2.2 release coming up at DevCon.
I'm "guessing" we're likely looking at about a month or two.. it's really hard to say depending on how many snags we run into. It's a fairly complicated piece of code. We'll have people starting to work on it full time in a few days from now.
03-24-2012 11:19 PM
I'm not thread jacking, but simply adding my comments. I've put together a very simple app with bbui.js (great framework, nice and lite) and I find that the focus based navigation is slow. Basically, the user interface experiences latency while moving around with the trackpad. If I speed up movement on the trackpad then I can't control or predict where the focus will land, invariably skipping the desired control and moving to the next. Are there any suggestions, or best practices to try and improve this behaviour? I've packaged the app with WebWorks SDK 22.214.171.124.
04-11-2012 09:01 PM
Are there specific bbUI controls that you are finding slow? The image list and inbox list seem to scroll pretty well.. But i've seen delays in the text arrow list that I haven't been able to track down. In theory it should be the same as the other lists, but it seems to take longer.. I'm wondering if it is some kind of event propagation slowing things down. I'll have to track the events through web inspector.
Right now I'm concentrating on having a set of BB10 controls ready in bbUI for BB10Jam
Can you also post the OS versions that you're testing with?
04-11-2012 09:07 PM
Yes I'm using text arrow list, and its pretty sluggish even with just a few items. OS7 here.
PS - not directly related but, is it a known bug that bbui.js doesnt loose the focus on elements when screens change? If I click my trackpad two times in a row, the screen changes twice like if I was still clicking the item on the previous screen. Hope this is clear enough...
04-11-2012 09:10 PM
Hmm didn't know about that click one. Can you log an issue on github for it.
Does it happen when clicking twice on an event that does a pushScreen? I'm wondering if it's triggering twice before the old screen is removed from the dom
04-11-2012 09:14 PM
It's not about the speed. I can wait 5minutes until the 2nd click, the behaviour is the same, it seems the focus remains on the other one.
Same thing happens If i remove an element which has focus. If I click without moving the trackpad, it still acts like the element exists.