930436 - The layout view should listen to reflow events, not paint events

Status: RESOLVED DUPLICATE of bug 997198

(DevTools :: Inspector, defect)

Comment 1

[Patrick Brosset <:pbro>]

As discussed Mike, I'm going to take a look at this bug.

There's already a reflow observer in the devtools' webconsole. See http://mxr.mozilla.org/mozilla-central/source/toolkit/devtools/webconsole/utils.js#2753
It's based on the docshell reflow observer which came with bug 453650.

The way it works is pretty simple, we just need to get the docshell which we're interested in, create an observer object that has reflow, reflowInterruptible and QueryInterface defined. And pass it to docShell.addWeakReflowObserver(observer);
Also, the observer will survive page reload and navigations, so we don't need to re-attach new observers everytime the page changes.

It'd be good to have this at the inspectorActor level, so that we could listen to reflow events in the layout-view (and possibly in other parts of the inspector if that makes sense).

The 2 questions I have are:

- do we need to worry about performance here? Like, is it ok to start the observer when the inspectorActor is initialized, and keep it running for the whole time until the actor is destroyed? Or do we need to have a startObserving/stopObserving kind of mechanism?
- is it worth extracting ConsoleReflowListener from webconsole/utils.js and put it into a separate module so we don't have to duplicate the code? I'd say yes, but I don't have any idea as to where that new file would like inside toolkit/devtools?

Paul, you worked on this, would you mind giving your point of view on these 2 questions?

Comment 2

[Paul Rouget [:paul]]

(In reply to Patrick Brosset [:pbrosset] [:patrick] from comment #1)
> - do we need to worry about performance here? Like, is it ok to start the
> observer when the inspectorActor is initialized, and keep it running for the
> whole time until the actor is destroyed? Or do we need to have a
> startObserving/stopObserving kind of mechanism?

I'm not sure. This needs to be investigated.

I believe it highly depends on what happens in the callback and how the notification is triggered. We ran into cases where activating reflow logs in the console was slowing down the page, but my guess it's because we don't batch the reflows before sending them over the protocol, and also because the console pipeline is complex.

Take a responsive page. Use a slow machine (or a debug build of Firefox). Open the inspector with the reflow listeners, and resize the page (this will throw many reflows). See how bad the perf regress.

Talk to dbaron or bz, they'll know better.

> - is it worth extracting ConsoleReflowListener from webconsole/utils.js and
> put it into a separate module so we don't have to duplicate the code? I'd
> say yes, but I don't have any idea as to where that new file would like
> inside toolkit/devtools?

If you find an efficient way to expose reflows, yes, it's worth it. Maybe in a follow up. Maybe we need a standalone reflow actor. Also, know that Firefox OS use the console API to get the reflow and print them.

Comment 3

[Patrick Brosset <:pbro>]

I'm going to fix this in bug 997198 directly in fact.