Looks like we can't reproduce the issue or there's a problem in the test case provided.
  1. #11
    Sencha User Jamie Avins's Avatar
    Join Date
    Mar 2007
    Location
    Redwood City, California
    Posts
    3,661
    Vote Rating
    18
    Jamie Avins is a jewel in the rough Jamie Avins is a jewel in the rough Jamie Avins is a jewel in the rough

      0  

    Default


    Quote Originally Posted by ilmiacs View Post
    Hi there,

    The same problem seems to be present in the 2.0.1 RC release.

    Just grab an iPad (I have 3rd gen.), go to Kitchen Sink -> UI -> Toolbar and watch the response times of the toolbar buttons:

    - The segmented buttons behave as expected: Immediate response

    - The other buttons behave badly: On an initial tap they rest in a pressed state for a noticeable delay. Subsequent taps on the same button then respond as expected. Sometimes, the buttons hang in the pressed state for an indefinite time, until an other button is pressed. This, however, is not reproducible.

    Latency is crucial for our application and we now decided to go native. While Sencha Touch provides a great GUI and has the great advantage of portability, we noticed that browser interpreted javascript is simply not snappy enough just yet for our latency-sensitive application, even for simple interactions. This decision is not solely related to the button latency described above.

    Peter
    Excellent, for the first time on the thread we've got a reproducible test case. This delay is almost certainly a webkit painting issue and we should be able to work around it.

    Sencha Inc

    Jamie Avins

    @jamieavins

  2. #12
    Sencha User Jamie Avins's Avatar
    Join Date
    Mar 2007
    Location
    Redwood City, California
    Posts
    3,661
    Vote Rating
    18
    Jamie Avins is a jewel in the rough Jamie Avins is a jewel in the rough Jamie Avins is a jewel in the rough

      0  

    Default


    Thank you again for the test case, as this led to a better fix for this issue. This override should resolve the button repaint issue, let me know if you encounter any problems:

    Code:
    Ext.define('Ext.button.override', {
        override: 'Ext.Button',
    
        onPress: function() {
            var me = this,
                element = me.element,
                pressedDelay = me.getPressedDelay(),
                pressedCls = me.getPressedCls();
    
            if (!me.getDisabled()) {
                if (pressedDelay > 0) {
                    me.pressedTimeout = setTimeout(function() {
                        delete me.pressedTimeout;
                        if (element) {
                            element.addCls(pressedCls);
                        }
                    }, pressedDelay);
                }
                else {
                    element.addCls(pressedCls);
                }
            }
        },
        doRelease: function(me, e) {
            if (!me.getDisabled()) {
                if (me.hasOwnProperty('pressedTimeout')) {
                    clearTimeout(me.pressedTimeout);
                    delete me.pressedTimeout;
                }
                else {
                    me.element.removeCls(me.getPressedCls());
                }
            }
        },
        doTap: function(me, e) {
            var handler = me.getHandler(),
                scope = me.getScope() || me;
    
            if (!handler) {
                return;
            }
    
            if (typeof handler == 'string') {
                handler = scope[handler];
            }
    
            //this is done so if you hide the button in the handler, the tap event will not fire on the new element
            //where the button was.
            e.preventDefault();
    
            handler.apply(scope, arguments);
        }
    });

    Sencha Inc

    Jamie Avins

    @jamieavins

  3. #13
    Sencha User
    Join Date
    Mar 2010
    Location
    Seattle, WA
    Posts
    137
    Vote Rating
    1
    wprater is on a distinguished road

      0  

    Default


    Quote Originally Posted by Jamie Avins View Post
    Unfortunately it doesn't put patch revisions in the forum integration at this time. We expect to release a candidate build for 2.0.1 tomorrow.
    Just wanted to confirm that this did not make it into 2.0.1rc?

  4. #14
    Sencha User
    Join Date
    Mar 2010
    Location
    Seattle, WA
    Posts
    137
    Vote Rating
    1
    wprater is on a distinguished road

      0  

    Default


    The override your provided is just for buttons, not for other tap events?

    We're having similar latency issues with our App that is nearing release. We're running 2.0.1rc.

  5. #15
    Ext JS Premium Member Steffen Hiller's Avatar
    Join Date
    Mar 2008
    Posts
    770
    Vote Rating
    28
    Steffen Hiller will become famous soon enough Steffen Hiller will become famous soon enough

      0  

    Default


    I'm dealing with this right now.

    Yesterday I successfully could completely remove the delay of my tabs in my tabbar (see http://www.sencha.com/forum/showthre...paint&p=777705).
    Since tabs are just children of Ext.Button, I thought I could do the same optimization for normal buttons in another part of my app,
    but so far no success.

    I tried the overrides = no difference, in fact it seems that with every second tap, the button handler is fired twice, but haven't looked into that further since I removed the overrides again since they didn't do a change.

    So the onPress seems to be called a bit earlier than my handler.
    Tried to change touchstart: to onTap, but somehow didn't really improve things.

    Will see if I can create an isolated test case.

  6. #16
    Ext JS Premium Member Steffen Hiller's Avatar
    Join Date
    Mar 2008
    Posts
    770
    Vote Rating
    28
    Steffen Hiller will become famous soon enough Steffen Hiller will become famous soon enough

      0  

    Default


    Note:

    The double calling of the handler only happens when you have an "alert" in your handler.
    After the first call, it shows alert and stays in press state, when hitting alert again, it unpresses and calls the handler again.
    So not sure if you want to take that as a bug.

    Continuing on trying to do a test case.
    At first try their is no delay in the test case, naturally.

  7. #17
    Sencha User Jamie Avins's Avatar
    Join Date
    Mar 2007
    Location
    Redwood City, California
    Posts
    3,661
    Vote Rating
    18
    Jamie Avins is a jewel in the rough Jamie Avins is a jewel in the rough Jamie Avins is a jewel in the rough

      0  

    Default


    Well alerts are a bit unusual, but any test cases help.

    Sencha Inc

    Jamie Avins

    @jamieavins

  8. #18
    Ext JS Premium Member Steffen Hiller's Avatar
    Join Date
    Mar 2008
    Posts
    770
    Vote Rating
    28
    Steffen Hiller will become famous soon enough Steffen Hiller will become famous soon enough

      0  

    Default


    For the double calling thing it's basically a normal button with handler: function () { alert('press') }.
    But well, not high prio i guess.

    Somehow the button part works ok for me for now.
    The pressing style is shown almost instantly. It stays in pressing state for a while till the new view is loaded, but that's ok for now, since at least the user gets almost instant feedback.

    I'm now looking into another performance problem: opening a sheet, which is super slow in my app,
    will keep ya updated.

  9. #19
    Sencha User
    Join Date
    Mar 2010
    Location
    Seattle, WA
    Posts
    137
    Vote Rating
    1
    wprater is on a distinguished road

      0  

    Default


    Quote Originally Posted by ilmiacs View Post
    Latency is crucial for our application and we now decided to go native. While Sencha Touch provides a great GUI and has the great advantage of portability, we noticed that browser interpreted javascript is simply not snappy enough just yet for our latency-sensitive application, even for simple interactions. This decision is not solely related to the button latency described above.
    Sadly, we're also switching to iOS as well because of performance reasons. The button tap latency, coupled with iOS aggressive DOM caching made for a poor experience.

  10. #20
    Touch Premium Member
    Join Date
    Nov 2011
    Posts
    5
    Vote Rating
    0
    jjamid is on a distinguished road

      0  

    Default I think we have the same problem

    I think we have the same problem


    We noticed that our application runs smoothly on devices running iOS 5 but is extremly slow on devices running iOS 4 (a matter of 5 - 10 seconds from the time something is touched until anything actually happens). This is not related to the iPhone/iPod version - iPod 3G with iOS 5 runs fine and iPhone 4 with iOS 4 has the problem.

    We are using ST2 Release version