Open Bug 605143 Opened 14 years ago Updated 2 years ago

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

Categories

(Core :: Layout, defect)

defect

Tracking

()

People

(Reporter: blizzard, Unassigned)

References

(Blocks 1 open bug)

Details

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.
--> 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.
Component: General → Layout
Product: Firefox → Core
QA Contact: general → layout
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.  ;)
I'm asking if this is the kind of thing we can fix before we move to multi-process?
If we try hard enough, probably....
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?
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.
In other words, what Chris wants is for the tabbar to be redrawn immediately, without waiting for the time to draw the content area.
Yes!
Is that really perceptually better, or do we end up feeling sluggish because the content lags behind the UI?
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?
> 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).
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.
Blocks: 846459
Blocks: tabswitch
OS: Windows 7 → All
Hardware: x86 → All
Version: unspecified → Trunk
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.