Search Unity

  1. Unity 6 Preview is now available. To find out what's new, have a look at our Unity 6 Preview blog post.
    Dismiss Notice
  2. Unity is excited to announce that we will be collaborating with TheXPlace for a summer game jam from June 13 - June 19. Learn more.
    Dismiss Notice

I think slow Android Touch Input ...

Discussion in 'Editor & General Support' started by mungtion, Apr 14, 2016.

  1. mungtion


    Apr 18, 2015
    Hi ~

    i tried 'touch & fast drag' test in android device.

    I have a problem about touch input sensitivity.

    i made simple script, just getting touch position in Monobehaviour update function.

    And apply to position of some image.

    like next picture.


    if quickly moved follow red line after touch screen. i could see image slowly follow 'touch position'.
    it like spring.


    i moved too fast 'blue start position' to 'red stop position' follow drag line.
    when i stoped at 'red stop position', i could see keep moving white image to 'red stop position'.

    Is it just Android IO speed problem ? Or Problem of unity ?

    Sensitivity is very important thing for me.

    who know anybody ?

    thank you.

    -- Sadly i not good at english .... i hope you understand what i saying. :)
    Last edited: Apr 15, 2016
  2. artplayer


    Apr 16, 2016
    Hello, I know the post is old but I'm exactly with the same problem. If you were able to solve, can you share the solution?

  3. 5argon


    Jun 10, 2013
    This problem is the drawback touch interpretation of Unity's polling-based Input API. In native Android, we receive touches via callbacks (may happen much more often than 60FPS frame rate) but in Unity, we ask the touch to use in-frame by

    What is in the
    right now is an interpretation of all native callbacks that happened before this frame. And so what you get from Unity is not necessary a present data. (Usually 1 frame late from the actual callback)

    Moreover, some data are lost because callbacks can be more than once per finger per frame. But Unity has to present exactly 1 data per frame (per finger). Some processing is required to conform with data polling based API. And it is different on iOS and Android.

    Look at this log comparing native callbacks with what you can check from Unity's API every frame. 9 callbacks became 3 data and the other 6 are lost with no relationship to what you get from Unity. (The circled with arrow ones became exactly what you get from Unity, with delta delta-ed to the previous ones skipping the rest, which I marked X)


    Of course, you still can only update you white box in-frame. But with native callbacks you would have more data Unity discarded to work on. (You can do your own bezier interpolation from them, etc.)

    (If you would like to receive native callbacks then you might be interested in Native Touch )

    (Also if you just want to know how Unity interpret native callbacks into
    API on both iOS and Android you can read my own deduction here :