"DOM is slow"

[Timothy Chien]

Hi,

I have change the the keyboard for it to listen to mousemove event
instead of touch events, so people would be able to slide their finger
to the correct key when that realize they were touching the wrong key by
looking at the highlight.

Then I realize the change of DOM (i.e., the position of the highlight)
got kind of queue up, so it doesn't really follows the finger moment in
time.

Demonstrated here:
http://www.youtube.com/watch?v=bOXsbrLVXw4#t=13

I would really like to do some performance profiling if I know how to do
it (will ask for help). In the mean time if someone else what to do it,
here are the details:

Code: https://github.com/timdream/gaia/tree/swipe
Demo on the web: http://timc.idv.tw/gaia-keyboard-demo

For swipe/slide gesture to work you would also need to make sure this
change of touch.js is included in your Gecko

https://bugzilla.mozilla.org/show_bug.cgi?id=716447


Tim

[Boris Zbarsky]

On 1/10/12 11:48 PM, Timothy Chien wrote:
> I would really like to do some performance profiling if I know how to do
> it (will ask for help). In the mean time if someone else what to do it,
> here are the details:
>
> Code: https://github.com/timdream/gaia/tree/swipe
> Demo on the web: http://timc.idv.tw/gaia-keyboard-demo

That demo doesn't seem to do anything obvious on mousemove. How do I
reproduce the slowness on the web demo?

-Boris

[Timothy Chien]

It doesn't slow on desktop, just the Gecko on the phone.

[Boris Zbarsky]

That said, if what you're doing involves updateKeyHighlight being called
on every mousemove, then there are a several of things that it's doing
suboptimally:

1) It's serializing and parsing some HTML on every mousemove.
2) It's probably doing at two relayouts on every mousemove (because it
changes content, then gets layout information, then changes styles).

It seems like the right approach here is to store what the last target
was for which we showed the highlight, and if that target hasn't changed
bail out early from updateKeyHighlight. And then move the innerHTML set
and className set down to where the style sets happen. And perhaps
double-check whether you really need innerHTML there or whether
something like textContent will actually do what you want? If you do
those, how do things look?

-Boris

[Boris Zbarsky]

On 1/11/12 12:19 AM, Timothy Chien wrote:
> It doesn't slow on desktop, just the Gecko on the phone.

Well, sure. But the point is if you say what the steps to reproduce are
I could profile even on desktop and see where time is spent. There's a
nontrivial chance that the information would carry over to phone, unless
the phone is having issues over in graphics-land.

-Boris

[Timothy Chien]

Thanks for the suggestions.

On line 340 there is a
if (this.currentKey == target) return;

so even there shouldn't be extra updateKeyHighlight() if the target.

For innerHTML, changing innerHTML on line 102 to textContent doesn't
seem to fix the slowness.

For className and style sets, it would really take two relayouts because
I need to know the offsetWidth (line 106) in order to calculate the
correct keyHighlightLeft.

[Boris Zbarsky]

On 1/11/12 12:51 AM, Timothy Chien wrote:
> For className and style sets, it would really take two relayouts because
> I need to know the offsetWidth (line 106) in order to calculate the
> correct keyHighlightLeft.

That's.... unfortunate. On your device, how long does
updateKeyHighlight take to run? How long does it take to run if you add
a layout flush at the end?

That said, I'd still appreciate a description of the actual steps to
reproduce (on desktop) whatever behavior you're performing.

-Boris

[Timothy Chien]

Humm...

On 1/11/12 2:05 PM, Boris Zbarsky wrote:
> On 1/11/12 12:51 AM, Timothy Chien wrote:
>> For className and style sets, it would really take two relayouts because
>> I need to know the offsetWidth (line 106) in order to calculate the
>> correct keyHighlightLeft.
>
> That's.... unfortunate. On your device, how long does updateKeyHighlight
> take to run? How long does it take to run if you add a layout flush at
> the end?

I tried to eliminate offsetWidth and put the className at the very end,
but the it doesn't seem to get any faster.

How do I measure the time of a individual function?

> That said, I'd still appreciate a description of the actual steps to
> reproduce (on desktop) whatever behavior you're performing.

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.

>
> -Boris

Regards,


Tim

[Boris Zbarsky]

On 1/11/12 11:32 AM, Timothy Chien wrote:
> How do I measure the time of a individual function?

var start = new Date;

at the beginning of the function.

var end = new Date;
console.log(end - start);

at the end of the function. If you're in an environment in which there
is no console log, use dump() or alert() or just add the string to the
page somewhere.

> 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.

-Boris

[Timothy Chien]

I made the measurement, it usually take 2-3ms and never exceed 5ms.

We should continue our conversation on the bug that is in place.

https://bugzilla.mozilla.org/show_bug.cgi?id=718913


Regards,


Tim