605143 - switching tab time is dependent on the complexity of the page you're switching to

Status: NEW

(Core :: Layout, defect)

Description

[Christopher Blizzard (:blizzard)]

I've noticed that when you're switching tabs the more complex pages (google docs, zimbra) cause the tab switch to take a lot longer.  Is there a way for us to invalidate & draw the tab before we try to invalidate & draw the page that we're drawing to?  I suspect it will make the browser feel much snappier since the reaction to the actual mouse click will be immediate.

Comment 1

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

--> Core::Layout

I don't think this is a tabbrowser change, but rather a change in the listeners and event handlers when we switch tab focus.

Comment 2

[Boris Zbarsky [:bzbarsky]]

Note that we generally try really hard to not paint things out of sync (e.g. painting the new tab with the old content area)...  But out-of-process might just solve this by default.  ;)

Comment 3

[Christopher Blizzard (:blizzard)]

I'm asking if this is the kind of thing we can fix before we move to multi-process?

Comment 4

[Boris Zbarsky [:bzbarsky]]

If we try hard enough, probably....

Comment 5

[Timothy Nikkel (:tnikkel)]

I don't understand what is being asked for here. If the delay in switching to the new tab isn't the painting of the new tab, then what is causing the delay?

Comment 6

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

I don't understand comment #0 either.

Comment 7

[Christopher Blizzard (:blizzard)]

Sorry.  The user is clicking on the tab.  One thing you can do to make that feel as fast as possible is to make sure that the reaction to that is immediate and the tab change (without the content) is drawn as fast as possible.  It makes the UI feel snappy.  Once that tab is drawn we can draw the content, but it disconnects the complexity of the page (which can slow redraws) from the responsiveness of the UI.  Out of process is one way to do this, but it's brute force.  I was asking if there was a way to do this in our current model.

Comment 8

[Boris Zbarsky [:bzbarsky]]

In other words, what Chris wants is for the tabbar to be redrawn immediately, without waiting for the time to draw the content area.

Comment 9

[Christopher Blizzard (:blizzard)]

Yes!

Comment 10

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

Is that really perceptually better, or do we end up feeling sluggish because the content lags behind the UI?

Comment 11

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

Yeah, I'm not sure that will have the desired effect. The best way to find out would be to understand what sort of delay we're introducing, but I expect that the flicker caused by going from:

Tab A content -> white -> Tab B content

would end up being more disruptive. What we'd really want to do is have a <canvas> image of the previous tab content and show that, then layout the page underneath and swap in. Or to just, you know ... actually be able to render page content we have in memory within 50-75ms so that it doesn't feel like there's a lag.

Chris: what are the characteristics of pages where you're seeing this?

Comment 12

[Boris Zbarsky [:bzbarsky]]

> actually be able to render page content we have in memory within 50-75ms

Note that switching to a background tab can involve layout of that background tab, not just rendering, depending on what else is going on.... (e.g. we suppress resize reflows in background tabs, but process them when the tab becomes visible).

Comment 13

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

Yeah, a particular test page and steps to reproduce that we can benchmark would be good.

If it's due to flushing tab resizes, we could flush out the resizes of the background tabs when we're idle, one at a time. That's probably a good idea even if it doesn't fix Blizzard's problem.