Open Bug 1459434 Opened 4 years ago Updated 3 years ago
.min _background _timeout _value" based on performance
Severity: normal → enhancement
Component: Untriaged → General
OS: Unspecified → All
Hardware: Unspecified → x86_64
In general, dynamically adjusting values like this can be tricky to get right, but it sounds like an interesting idea. Ehsan, do you have any thoughts on this?
Priority: -- → P3
We now throttle timeouts in the background based on actual time used. That budget based throttling should automatically account for slow hardware.
Agreed with Ben. That approach has the additional benefit that it's a heuristic that works across browsers now. Daniel, do you see Chrome also show the same kind of sluggish behavior that you see in Firefox with the same number of tabs? I'm asking since Chrome has the same budget based throttling mechanism as we do, so our behaviors should be the same more or less.
Chromium (does that count, too?) has with 20+ Tabs about the same slugishness as Firefox has. On this Notebook with Intel N3540 and on my Chromebook (GalliumOS) with Intel N2840, too. Cause the integrated graphics are really weak, i already disabled OpenGL-rendering, which improved performance. I too had issues with ugly font-rendering, which i fixed with use of cairo instead of skia. No such issue in Chromium. In search for further improvement of responsiveness, i stumbled over that thing with "dom.min_background_timeout_value". Additional note: Currently i use the 52 LTS release with forced multiprocessing. There's no budget based throttling? Would the performance with the now released 60 LTS improve? I prefer to stick with LTS.
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.