Closed Bug 816538 Opened 12 years ago Closed 12 years ago

Keyboard is really slow because every key press repaints the whole SMS app

Categories

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

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(blocking-basecamp:+)

RESOLVED WORKSFORME
blocking-basecamp +

People

(Reporter: ttaubert, Assigned: ttaubert)

Details

Attachments

(1 file)

I suggest this should be blocking because the keyboard is much faster in e.g. the calendar app. The SMS app does something stupid and is slower. People will spend much more time typing in the SMS app.
This is caused by the sliding "optimization": https://github.com/mozilla-b2g/gaia/commit/2c360dfd3a3792e575fd0040b2b2d3bb3e6eb8b7 This uses moz-element(body) as a background and repaints a lot.
There's an existing bug on file for this which I can't find off-hand. Let's consolidate.
Comment on attachment 686671 [details] Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/6720/files Works much better as before and doesn't repaint the whole screen when pressing a key on the keyboard. Still not on par with the calendar app but we can investigate that in a follow-up.
Attachment #686671 - Flags: review?(21)
Why removing the 'snapshot' is 'optimizing' the keyboard? We had the same in contacts and it's working properly, why do we have to remove it here? The transition is made in order to have a smooth slide, better than moving both panels (that's why we are using it!). I think that I know where is the problem. Let me check one thing and I will send a patch.
We are trying to make the keyboard fast everywhere and this hack does not fit with this key component. https://github.com/mozilla-b2g/gaia/commit/b8eb129d75c3f16e1d06282aa5a347f277923dd9
Status: ASSIGNED → RESOLVED
blocking-basecamp: ? → +
Closed: 12 years ago
Resolution: --- → FIXED
(In reply to Borja Salguero [:borjasalguero] from comment #5) > Why removing the 'snapshot' is 'optimizing' the keyboard? We had the same in > contacts and it's working properly, why do we have to remove it here? The > transition is made in order to have a smooth slide, better than moving both > panels (that's why we are using it!). I think that I know where is the > problem. Let me check one thing and I will send a patch. If you specify a |background: -moz-element(#main-wrapper)| we will have to repaint the whole #main-wrapper element. I don't see why moz-element's double painting in combination with scaling should be faster than using a simple translateX() transform. The slide animation is smooth. If you really write a patch make sure to turn on paint-flashing to see if a key press repaints the whole screen.
Gecko-cfad7c9 Gaia-6c53dfd
Resolution: FIXED → WORKSFORME
Whiteboard: dupeme
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: