Open Bug 752630 Opened 12 years ago Updated 2 years ago

Something(refresh driver?) causing a reduction in ctrl+tab drawing rate

Categories

(Core :: Layout, defect)

Product:
Core
Component:
Layout
Platform:
x86_64
Windows 7
Type:
defect

Tracking

()

People

(Reporter: taras.mozilla, Unassigned)

Details

(Whiteboard: [Snappy:P1]) 

On fast hardware when one holds down ctrl+tab, every tab is drawn in sequence. On slower hardware we seem to be skipping frames and the frame skipping logic causes us to paint over every couple of seconds vs x-frames/second.
This gets into a funny situation where if one switches one tab at a time at a certain rate one can see tabs switch faster than when holding down ctrl+tab when the frame-skipping path is hit.
Does reducing the refresh interval help?  Does turning of the delay line stuff in timerimpl help?
(In reply to Boris Zbarsky (:bz) from comment #1)
> Does reducing the refresh interval help?  Does turning of the delay line
> stuff in timerimpl help?

layout.frame_rate makes no differences. I don't know what that other thing is
bz, were you referring to nsITimer->SetDelay() ?
> I don't know what that other thing is

The thing that guesses when to "really" fire timers.

To turn it off, change the 1.5 at http://hg.mozilla.org/mozilla-central/file/e4f9e2eab6b1/xpcom/threads/TimerThread.cpp#l241 to a 0.
When I saw this I checked my Firefox 11 build on that machine as well, and it didn't seem to happen there. Does anyone see the same behaviour?
Try adding some logging to nsWindow::DispatchPendingEvents to determine
-- If it's being called regularly
-- If it's calling nsWindow::DispatchStarvedPaints regularly (and if not, why not!)
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.