579488 - typing in text entry box on twitter is incredibly slow (again)

Status: VERIFIED FIXED

(Core :: Graphics, defect)

Description

[Mike Beltzner [:beltzner, not reading bugmail]]

Same sort of symptoms as in bug 488901 - I'm seeing it on Windows, not sure if it happens on OSX or Linux.

STR:
1. Login to a twitter.com account on their website
2. Type in the "Tweet this" box

Expected: normal typing latency
Actual: OMG SLOW typing latency

I suspect retained layers, but that's mostly because it's the biggest recent change. It's been a while since I used Windows, so it may have regressed earlier.

Comment 1

[Joe Drew (not getting mail)]

I can reproduce this on Mac too! It's not as obvious as on Beltzner's computer, but this is also a faster machine than Beltzner's.

Comment 2

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

I've actually seen this as early as a week or two ago, without retained layers.  Should've filed, sorry!

Comment 3

[Joe Drew (not getting mail)]

We probably need someone to profile this in addition to/along with finding a regression window. Volunteers? :)

Comment 4

[Mike Beltzner [:beltzner, not reading bugmail]]

If someone tells me how, I can profile it.

Comment 5

[(no longer active)]

Attachment: Shark profile

Comment 6

[Joe Drew (not getting mail)]

A lot of the time in the profile is spent drawing. I wonder if the dirty regions are too big while we're typing?

Comment 7

[Jeferson Hultmann]

Actually this issue still happens in version 3.6: http://search.twitter.com/search?q=firefox+twitter+slow

Since Firefox 3.6 launch, users from my locale say they had to downgrade in order to use Twitter again. Unfortunately, I've never been able to reproduce this issue.

Comment 8

[Mike Beltzner [:beltzner, not reading bugmail]]

Is there anything I can do to debug this when it happens?

Comment 9

[Robert O'Callahan (:roc) (email my personal email if necessary)]

so it's intermittent for you?

Comment 10

[Mike Beltzner [:beltzner, not reading bugmail]]

No, it's consistent, Windows-only. en-US build, and my personal location is consistently north america.

Comment 11

[juan becerra [:juanb]]

I noticed this today. It's happening on Linux (Ubuntu) too (64bit) 4.0b8pre 20101018.

Comment 12

[Graydon Hoare :graydon]

Seeing this on linux, win7 and osx. Linux is worst, windows medium, mac tolerable.

Tracking nightlies.

Comment 13

[Graydon Hoare :graydon]

A small additional note: the page has several thousand CSS rules active and claims to use the "sizzle CSS engine"; I turn off CSS there is no problem.

Comment 14

[Timothy Nikkel (:tnikkel)]

Attachment: reduced version

This is a reduced version that I'm not claiming represents all the problems with slow twitter typing.

It automatically enters some text so I can get some hard numbers and don't need to rely on "feel".

Turning off CSS fixes the problem because it makes us not do any of the difficult things (border radius, box shadow, fixed background).

Comment 15

[James May [:fowl2]]

(For people with the new twitter - clicking on the little square with a pencil in it next to your username in the top write, and using that box is muuuuch better)

Comment 16

[Mike Beltzner [:beltzner, not reading bugmail]]

David Tenser notes in bug 606461 that there seems to be a difference between us and Chrome in terms of when we're firing events which update the character counter. Possibly related?

Comment 17

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Is this noticeably better (or even fixed) now that the dependent bugs are fixed?

Comment 18

[Timothy Nikkel (:tnikkel)]

I still find it slow, the reduced version I posted got faster though.

Comment 19

[Boris Zbarsky [:bzbarsky]]

Note bug 606461?

Comment 20

[Timothy Nikkel (:tnikkel)]

Attachment: new reduced version

I have a new reduced version that is still slow and it doesn't do anything crazy.

The slowness that I am talking about is being able to lift your hands from the keyboard and watch the last word you typed appear, not tiny effects with a single character.

In reducing this I came across an instance of -moz-box-shadow being specified but not box-shadow or -webkit-box-shadow. The css is huge, so I can't tell if it was specified somewhere else for the other browsers (every other instance had them all specified together though).

Comment 22

[Timothy Nikkel (:tnikkel)]

So the problem here is that anytime we reflow an inline line in a block we invalidate the entire line no matter what (http://mxr.mozilla.org/mozilla-central/source/layout/generic/nsBlockFrame.cpp#2541) even if what we are reflowing is several layers deeper and nothing moves. Display list based invalidation should fix that (bug 539356), but its not something we can do for FF4, and it doesn't look like there is anything we can do in the FF4 timeline to help with this.

The actual painting that this causes is slow for two reasons. Twitter uses border-radius, and it uses overflow: hidden on an element that has border-radius. This seems to be slow because drawing with a rounded rect clip is not as fast as it could be (bug 607540). The other reason is Twitter uses box-shadow which we can speed up (bug 509052). Combining box-shadow with border-radius makes it even slower as we need to do more work.

Comment 23

[Robert O'Callahan (:roc) (email my personal email if necessary)]

When drawing with a clip path like the rounded-rect clip, cairo applies the clip mask to every drawing operation separately. We can avoid that by pushing a temporary group and then setting the complex clip only when drawing the group back to the destination. I know you tried that, what was the result?

Comment 24

[Timothy Nikkel (:tnikkel)]

It ended up being the same or slower. Even just a simple solid color fill is slowed down by using a rounded rect clip.

Comment 25

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Can you explain why it wasn't faster? It seems to me that if we do ten drawing operations and mask each one, that must be a lot slower than doing ten unmasked drawing operations to a temporary surface and then copying that back with a mask.

Comment 26

[Timothy Nikkel (:tnikkel)]

If we push a group then we either need to push a group with color+alpha (potentially making us do more work) or copy the background into the pushed group, which is more work as well. In the simplified testcase at least there is basically one large paint (the background of the large div with border radius) and a few small paints, the cost of painting those smaller items is probably small.

Comment 27

[Timothy Nikkel (:tnikkel)]

Looks like the cairo 1.10 update (bug 562746) takes care of the border radius slowdown issues. It also improves the box-shadow plus border-radius case too, but there is still a significant slowdown.

Comment 28

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Is the slowdown all in gfxBlur now?

Comment 29

[Timothy Nikkel (:tnikkel)]

When adding box-shadow (when we already have border-radius) BoxBlurHorizontal and BoxBlurVertical are responsible for about 10% of the runtime each, and there is another extra 10% in misc cairo functions that only show up with border-radius and box-shadow (not there if we only have one).

Comment 30

[Asa Dotzler [:asa]]

When I'm typing quickly in the twitter box (today's trunk nightly on win 7 with no hardware acceleration) it falls well behind and when I stop, after a second or so it catches up but what's really odd is that very briefly as it's filling in all the missing text, the Firefox window flashes and a new Firefox window shows up very briefly in the Windows 7 taskbar and then just as quickly disappears. I can reproduce this quite easily.

Comment 31

[Asa Dotzler [:asa]]

Also, the reduced testcases are quite fast for me with today's trunk build on win7 but actual textarea on newtwitter is still dogslow.

Comment 32

[Timothy Nikkel (:tnikkel)]

I can't reproduce the thing about the window popping up, but it should be investigated to see what is going on.

The testcases that are posted in this bug aren't really relevant anymore.

Comment 33

[Johnathan Nightingale [:johnath]]

(In reply to comment #30)
> When I'm typing quickly in the twitter box (today's trunk nightly on win 7 with
> no hardware acceleration) it falls well behind and when I stop, after a second
> or so it catches up but what's really odd is that very briefly as it's filling
> in all the missing text, the Firefox window flashes and a new Firefox window
> shows up very briefly in the Windows 7 taskbar and then just as quickly
> disappears. I can reproduce this quite easily.

I see almost precisely this behaviour on 32-bit vista as well. Slow typing, flash where my window content disappears and then the typing catches up (though sometimes with missed characters). Rinse, repeat.

I don't see a new window in the task bar, but I *do* see that when the browser content disappears, I will sometimes see an image from the last video content displayed - almost like I'm seeing stale framebuffer content or something.

I appreciate how frustratingly vague that is. Are there things I can do to get you better data? Turning off acceleration eliminates the flashing for me, reliably.

Comment 34

[Boris Zbarsky [:bzbarsky]]

Do we end up reframing a large chunk of the frame tree on each keystroke or something?  Someone with a debug build and a twitter account should be able to check that...

Comment 35

[Johnathan Nightingale [:johnath]]

Attachment: Blown out window content

(Just to be clear since I realize comment 33 is misleading, when I refer to browser content disappearing, I mean everything, including chrome. See attachment. If this is unhelpfully different than Asa's complaint, I can move to a different bug, too).

Comment 36

[Boris Zbarsky [:bzbarsky]]

Oh, I see.  And that effect disappears if you turn off hardware accel, but the slow typing remains?

Comment 37

[Johnathan Nightingale [:johnath]]

I'll double check tonight. I know the disappear/reappear goes away, but when I originally spotted that problem, I didn't realize it was tied to twitter typing (and that's not the only time it happens) so I'm not sure I checked typing speed.

Comment 38

[Timothy Nikkel (:tnikkel)]

I think this new issue with everything disappearing or a new window opening is something different since twitter has been slow since before we had hardware acceleration, in fact since at least 3.6. So we should split that off and investigate it.

Comment 39

[Timothy Nikkel (:tnikkel)]

Filed bug 617465 for the new window briefly appearing bug.

I can't reproduce the everything disappearing, maybe it's a hardware or driver issue given that it requires hardware acceleration.

Comment 40

[Robert Sayre]

I can reproduce the slow typing on linux with no acceleration enabled.

Comment 41

[Joe Drew (not getting mail)]

We never claimed it had anything to do with hardware acceleration. Twitter's not unusable, it's just slow.

Comment 42

[Robert Sayre]

Also, I set this to be a hard blocker. Typing in twitter has to be fast.

Comment 43

[Joe Drew (not getting mail)]

Yes, that's why it's a blocker.

Comment 44

[Timothy Nikkel (:tnikkel)]

As much as I want to fix this bug (and I do) we should remember that typing in twitter has been slow since at least 3.6 (although it has gotten worse for 4). I have some things in mind that can make 4 to improve the situation, but I'm afraid we might not be able to solve the problem completely in time for 4. (We know how to solve it, just not in time.)

Comment 45

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Is this something that we can evangelize with twitter, to have them fix on their site?  It's not ideal, but if there's something specific that they're doing, we may be able to suggest alternates that are faster.

Comment 46

[Robert Sayre]

(In reply to comment #45)
> Is this something that we can evangelize with twitter, to have them fix on
> their site?  It's not ideal, but if there's something specific that they're
> doing, we may be able to suggest alternates that are faster.

yeah, we might want to try that. See

http://www.alexa.com/topsites

Twitter is #10. We cannot ship with twitter working this way.

Comment 47

[Asa Dotzler [:asa]]

Do we know anyone there? Could we try to get them to "fix" this?

Comment 48

[Robert Sayre]

Timothy, there a fix you can suggest that would give the twitter guys basically the same visual effect, but perform well in Firefox 4?

Comment 49

[Graydon Hoare :graydon]

(In reply to comment #45)
> Is this something that we can evangelize with twitter, to have them fix on
> their site?  It's not ideal, but if there's something specific that they're
> doing, we may be able to suggest alternates that are faster.

(01:18:19 PM) matasar: you should email the following people:
(01:18:47 PM) matasar: me ([e-mail]), dustin diaz ([e-mail]), and dan webb ([e-mail])

Someone who knows the exact failure mode in the content want to get emailing?

Comment 50

[Timothy Nikkel (:tnikkel)]

Yes, there is something simple twitter can change to make the problem go away (make the characters left count from a span to a textbox). I sent an email to the three addresses in comment 49.

Comment 51

[Timothy Nikkel (:tnikkel)]

There is one thing which would pretty much solve the issue on our end that could possibly make 4, upgrading to cairo 1.10 (bug 562746). But right now that looks doubtful to make it.

Comment 52

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

oh my god, 1.10 didn't make it in? aaaa.

Comment 53

[Robert O'Callahan (:roc) (email my personal email if necessary)]

What changed in cairo 1.10 to make clipping to a rounded rect so much faster?

Comment 54

[Timothy Nikkel (:tnikkel)]

I don't know. Jeff didn't know off the top of his head either when I asked him a while ago.

Comment 55

[Timothy Nikkel (:tnikkel)]

What do people think about the speed typing in the tweet box in the latest nightly (2011-01-27)?

Comment 56

[Asa Dotzler [:asa]]

I noted in comment 31 that before I was easily able to type fast enough that when I stopped, the rendering was slow enough that characters continued to appear seconds after I'd stopped.  In today's nightly build I cannot type fast enough to see any rendering after I stop typing. Or, to put it another way, Firefox does not fall behind my typing. This is "fixed" well enough for my needs. Testing on a core2 duo 1.4GHz with integrated intel graphics running Windows 7.

Comment 58

[Graydon Hoare :graydon]

Remains unusably slow on latest nightly for me. Linux (core 2 duo, 2.6ghz) especially bad, OSX (core 2 duo, mini) tolerable but I can easily induce a >2s "watch the text still appear on the screen for a while after I stopped typing" lag by typing ahead of it.

I would reopen this, personally. I'm not in a bug-driving position but it feels unfixed to me.

(For that matter, even the mouseover highlighting of tweets visibly lags on twitter.com.)

Comment 59

[Graydon Hoare :graydon]

(In reply to comment #58)
> Remains unusably slow on latest nightly for me.

False alarm, sorry. Off by one on the nightlies. It's still perceptible as lag, but has improved to the point of usability.

Comment 60

[Timothy Nikkel (:tnikkel)]

(In reply to comment #59)
> False alarm, sorry. Off by one on the nightlies. It's still perceptible as lag,
> but has improved to the point of usability.

Yeah, we have a longer term plan to make it completely fast.

Comment 61

[Timothy Nikkel (:tnikkel)]

I saw the improvement on Ehsan's mac too, it was pretty good.

Comment 62

[(no longer active)]

(In reply to comment #61)
> I saw the improvement on Ehsan's mac too, it was pretty good.

He's too humble.  He didn't mention the amazing performance that we saw on Windows as well.  :-)

Comment 63

[James May [:fowl2]]

100% CPU usage while typing, but it doesn't *feel* laggy any more (except for the spellcheck catching up).

This is on a 1.7ghtz Pentium M w/ W7, so a vast improvement. 

Thanks =)

Comment 64

[Robert M. Enger]

hi:
My bug submission  629278 has been declared a duplicate of this bug.  
So I am sending a status report here.

I am now running Minefield 4.0b11pre (2011-01-29).  It is NOT ANY BETTER.

Simply shifting focus into the twitter "what's happening" (tweet composition) box and holding down the DELETE KEY will max out the cpu.  (47% to FF, 6 to 8% system).  Chrome and IE8 keep up with key repetition-rate and do not max-out the CPU.       This bug is NOT RESOLVED/FIXED.

FF is NOT keeping up with the keyboard keystroke-repetition rate, it is constraining it due to the CPU being maxed out.

I have no idea what manner of dumb **** coding that the Twitter web folks are using, but whatever it is FireFox does not like it.  There are supposed to be a LOT of Twitter users (100M+???). It's probably worth fixing FF to better support Twitter text entry.

Comment 65

[Boris Zbarsky [:bzbarsky]]

Robert, sounds like bug 629278 is not in fact a duplicate of this bug.  I've reopened it.  Thank you for retesting!

Comment 66

[Steve Scott (pxbugz)]

Verified fixed in Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b12pre) Gecko/20110204 Firefox/4.0b12pre

Comment 68

[Techni Myoko]

It's baaaaaack.

Comment 69

[Boris Zbarsky [:bzbarsky]]

Please file a new bug with specific steps to reproduce and cc me?

Comment 70

[Techni Myoko]

(In reply to Boris Zbarsky [:bzbarsky, bz on IRC] from comment #69)

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

Included a screenshot of the new theme so you know what I mean by that.

Comment 71

[Techni Myoko]

It's baaaaaaack, again.

Comment 72

[Boris Zbarsky [:bzbarsky]]

Right, that's bug 1527786, no?