I'm a big fan of it working, because I believe that it's a key component
to handling correctly slow scripts.
Cheers,
David
On 29/06/15 02:14, Nathan Froyd wrote:
> If you are referring to bug 715376 (and related), those patches are
> still in my queue, fully rebased. We only need to decide that
On Sun, Jun 28, 2015 at 5:14 PM, Nathan Froyd wrote:
> On Sun, Jun 28, 2015 at 5:23 PM, Mike Hommey wrote:
> >
> > BTW, wasn't there an effort a few couple years ago, to move content
> > event loop in different threads for different tabs? What happened to
> > that?
> >
>
> If you are referring t
Nathan, it looks like the SessionRestore feature that was causing test failures
has been removed by Tim in the meantime… Does that mean that the 'possible
webcompat issues’ is the only real issue left?
If so, I’d suggest to request feedback from :annevk and/ or :dbaron (for
example) to get a fe
On Sun, Jun 28, 2015 at 7:55 PM, Vladan D wrote:
> I asked Avi to work on pausing GC/CC during scrolling in Q3 & Q4 2014. I
> still think it's relevant but process-per-tab will give some of the same
> benefits
>
Olli is working on creating some kind of unified scheduler for the giant
mess of GC
On Sunday, June 28, 2015 at 4:09:18 PM UTC-4, David Rajchenbach-Teller wrote:
> Actually, I was just thinking about introducing a "priority-to-60fps"
> mode, activated e.g. while the user is scrolling the foreground tab, or
> perhaps during animations in the foreground tab.
>
> Whenever we are run
On Sun, Jun 28, 2015 at 5:14 PM, Nathan Froyd wrote:
> On Sun, Jun 28, 2015 at 5:23 PM, Mike Hommey wrote:
> >
> > BTW, wasn't there an effort a few couple years ago, to move content
> > event loop in different threads for different tabs? What happened to
> > that?
> >
>
> If you are referring t
On Sun, Jun 28, 2015 at 5:23 PM, Mike Hommey wrote:
>
> BTW, wasn't there an effort a few couple years ago, to move content
> event loop in different threads for different tabs? What happened to
> that?
>
If you are referring to bug 715376 (and related), those patches are still
in my queue, fully
On Mon, Jun 29, 2015 at 06:23:30AM +0900, Mike Hommey wrote:
> On Sun, Jun 28, 2015 at 10:09:04PM +0200, David Rajchenbach-Teller wrote:
> > On 28/06/15 20:39, Randell Jesup wrote:
> > >>> I was under the impression that because e10s is only a single process
> > >>> for
> > >> all content (at leas
On Sun, Jun 28, 2015 at 10:09:04PM +0200, David Rajchenbach-Teller wrote:
> On 28/06/15 20:39, Randell Jesup wrote:
> >>> I was under the impression that because e10s is only a single process for
> >> all content (at least right now) a background tab can still negatively
> >> affect the foreground
On 28/06/15 20:39, Randell Jesup wrote:
>>> I was under the impression that because e10s is only a single process for
>> all content (at least right now) a background tab can still negatively
>> affect the foreground tab.
>>
>> That's right, but we also tested e10s in the process-per-tab configurat
>> I was under the impression that because e10s is only a single process for
>all content (at least right now) a background tab can still negatively
>affect the foreground tab.
>
>That's right, but we also tested e10s in the process-per-tab configuration
There are other options for background tab
> I was under the impression that because e10s is only a single process for
all content (at least right now) a background tab can still negatively
affect the foreground tab.
That's right, but we also tested e10s in the process-per-tab configuration
> Have we ever considered building something lik
From your blog post:
> Heavy activity in background tabs badly affects desktop Firefox’s
scrolling performance1 (much worse than other browsers — we need E10S)
I was under the impression that because e10s is only a single process for
all content (at least right now) a background tab can still neg
13 matches
Mail list logo
