1122274 - Low performance of keyboard starting from b2g 2.1

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: Gaia::Keyboard, defect)

Description

[mac]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:35.0) Gecko/20100101 Firefox/35.0
Build ID: 20150108202552

Steps to reproduce:

Typed in SMS message.


Actual results:

The keyboard performance in 2.1, 2.2 and 3.0 is significantly lower than it was in 2.0, as shown on those videos:

Taken on 2.0 - high performance of keyboard:
https://www.youtube.com/watch?v=f1_ijMet_Ac

Taken on 3.0 - low performance of keyboard, delay between pressing keys is easily visible:
https://www.youtube.com/watch?v=Zz0RNuKaWQU


Expected results:

Keyboard performance should be not worse than it was in previous versions.

Comment 1

[u495161]

Actually performance of entire system is getting worse in my opinion, but yes, your videos are showing the difference. I do not have comparision to older build, but I can say that on mine 3.0 it looks like yours.

Comment 2

[mac]

Tim, could you take a look on it?

Comment 3

[Tim Guan-tin Chien [:timdream] (please needinfo)]

It would be hard to identify where the problem is simply by looking at the two videos. 
I can't think of any changes in the code that could cause this on top of my head -- all changes in API and the code recently are all about switching between input targets / apps, not the actual key strokes.

Let me flag qawanted first to see if it's possible to find a regression bug. If this is not something QA will be able to help feel free to remove the flag.

Comment 4

[Pi Wei Cheng [:piwei] (inactive)]

We generally don't do regression windows on performance issues because often times it's not one single change that caused the issue. Also we've retired Buri device since 2.0 was master and we're not observing keyboard issues on current Flame branches as far as I know.

Comment 5

[mac]

(In reply to Pi Wei Cheng [:piwei] from comment #4)
> We generally don't do regression windows on performance issues because often
> times it's not one single change that caused the issue. Also we've retired
> Buri device since 2.0 was master and we're not observing keyboard issues on
> current Flame branches as far as I know.

Then as I understand nothing is going to be done with it in such situation?

Comment 6

[Pi Wei Cheng [:piwei] (inactive)]

(In reply to mac from comment #5)
> Then as I understand nothing is going to be done with it in such situation?

This means there's only so much that QA (myself) can do to help resolve a bug. For this issue the developers are on their own to resolve it.

Comment 7

[[:fabrice] Fabrice Desré]

Tim, can you check on your side the perf regression reported here? I don't think it's that important to get a regression range but we need to understand what makes us slow and fix it.

Comment 8

[mac]

This is blocking issue for all who still use hamachi. I know - it is no longer supported. But when the issue will be fixed many people (i.e. in Poland but I'm sure not only) would move forward and change to master. Now they stuck on b2g 2.0.

Comment 9

[Penserbjorne - MexMod]

Not only in Poland, here in Mexico many people still have and use their hamachi, in MexMod we are compiling roms for this device and many users has reported problems with the keyboard and the low performance since 2.2 version. Please let us know where is the problem or how to fix it :)

Comment 10

[Tim Guan-tin Chien [:timdream] (please needinfo)]

(In reply to Fabrice Desré [:fabrice] from comment #7)
> Tim, can you check on your side the perf regression reported here? I don't
> think it's that important to get a regression range but we need to
> understand what makes us slow and fix it.

I just re-watched the video. I wonder if it's a perceived delay instead of a real delay? We adjusted the timing of removing the highlight in bug 1039163, bug 957031, and bug 971446 by moving the impl from CSS visibility transition to JavaScript.

Other than that we did not make any substantial changes to the key handling since v1.4 (bug 1013570). MozInputContext#sendKey() is called after the previous sendKey() resolves/rejects and invoke the chained then() method. It might worthy to measure the time of the call v.s. the time of the touchend event because the code is a little but complex than before though, but I highly doubt JavaScript execution can slow us down that much.

After the MozInputContext#sendKey() call the problem of responsiveness would be in the realm of IPC messaging & internal API impl. We didn't change mozInputMethod API a lot either so maybe something about our IPC path is slow us down a lot? The current impl awaits main loop to be available in three processes -- b2g, app, keyboard -- if b2g process is slow the keyboard API is gonna to be slow.

Comment 11

[BMO Automation]

Firefox OS is not being worked on