Closed Bug 718913 Opened 13 years ago Closed 13 years ago

Tracking: Make Gaia IME fast

Categories

(Core :: General, defect)

Product:
Core
Component:
General
Platform:
ARM
Gonk (Firefox OS)
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: cjones, Unassigned)

References

Details

The IME has a really cool feature where pressing and holding a character will present variations on the character, like accented characters. It works great but sliding ones finger around the character-selection screen has bad perceived responsiveness; the highlighted key lags way behind the finger. See more details below http://groups.google.com/group/mozilla.dev.b2g/browse_thread/thread/ebfe982d881acb57/99301f8c21aabd5c?lnk=gst&q=dom+is+slow#99301f8c21aabd5c There's at least one piece of low-hanging fruit to be plucked here, tracking the rest off this bug.
Tim, from the newsgroup thread > > Sorry about missing the question: the step to reproduce on desktop is > > simply hold down the left button of the mouse and move across the keys > > on keyboard; the highlight should move with the cursor without delay. > > Thanks. > > So a profile on desktop shows that over half the time is painting. The > rest is about as expected; nothing obvious jumping out. > > Would be good to get some data on the execution time for > updateKeyHighlight so we have an idea of where time is being spent on > the device. Did you ever get any timings from updateKeyHighlight() on device?
(In reply to Chris Jones [:cjones] [:warhammer] from comment #1) > Did you ever get any timings from updateKeyHighlight() on device? No, will do when I get my phone back (I hit the MediaServer crashing bug) But I can tell you right now that even if comment out the updateKeyHighlight function, the key active gradient (triggered by target.dataset.active and the .keyboard-key[data-active] {} css selector) is still slow.
Oh, gradients! Those along with transparency (and excessive invalidation/reflow) could be contributing to the slowdown. Is the animation noticeably faster if you disable gradients and transparency? How about just disabling one or the other?
(In reply to Chris Jones [:cjones] [:warhammer] from comment #3) > Oh, gradients! Those along with transparency (and excessive > invalidation/reflow) could be contributing to the slowdown. > > Is the animation noticeably faster if you disable gradients and > transparency? How about just disabling one or the other? No, neither disable gradient nor transparency would make it any faster. > Did you ever get any timings from updateKeyHighlight() on device? The entire mouseover function usually take 2-3ms, 6ms as most occasionally.
OK, so it sounds like work is happening async from that. If you add a layout flush at the end of the mouseover, how long does the mouseover take? If it's still quick, then the issue is likely painting....
(In reply to Boris Zbarsky (:bz) from comment #5) > OK, so it sounds like work is happening async from that. > > If you add a layout flush at the end of the mouseover, how long does the > mouseover take? If it's still quick, then the issue is likely painting.... How do I do a "layout flush"? I am sorry I don't familiar with rendering engine terminologies...
It would be fabulous if someone could analyze what's slow in here. Testing on the sgs2 is best. We already know of bug 718914, but something in the layout/rendering of the page is causing us not to keep up with the input events.
Depends on: 718914
s/page/IME keyboard/
The original perf problems are gone. Not sure what made them go away. Let's file new bugs for new perf problems, or problems on different devices.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.