See https://github.com/tarasglek/browser-power/blob/master/README.md for methodology. This is a haswell laptop with hw accel.

On the other hand, we pretty much match IE on fishtank https://dl.dropboxusercontent.com/u/5961467/fishbowl.png

Can you get a profile for this situation?

(In reply to Jeff Muizelaar [:jrmuizel] from comment #2) > Can you get a profile for this situation? I was hoping a graphics person would.

Other questions: - Does IE scroll the amount when pressing down? - Does IE do smooth scrolling (is the scroll when pressing down animated)

Async pan/zoom is currently being worked on and will affect the amount and type of painting we do. It will likely result in less display list processing but more painting. It may be useful to compare direct2d with cairo.

Bas helped me determine that the overhead comes from layout inefficiency.

Could you provide additional detail?

(In reply to David Baron [:dbaron] (don't cc:, use needinfo? instead) from comment #7) > Could you provide additional detail? So, we're doing this with smooth scrolling, that means that we're trying to basically draw a single line of pixels every time. This means the amount of graphics work we're actually doing is fairly low. My theory is that the overhead of generating the display items and setting everything up for drawing for each frame of scrolling is part of what's causing the high amount of CPU power used. What I'm not certain about is if there's a lot that layout can do short term to improve this a lot. (I know display list retention is being worked on) When we have tiling on desktop this will help a lot but that's still going to take a while, I believe this is the improvement Anthony Jones is referring to :-). The latter is the big win we can get here, as regardless of what we do, drawing one line at a time is never going to be the most power efficient way. (In reply to Jeff Muizelaar [:jrmuizel] from comment #4) > Other questions: > - Does IE scroll the amount when pressing down? > - Does IE do smooth scrolling (is the scroll when pressing down animated) From what I could see the answer to the second question is yes. I'm not 100% sure what the first question means. (In reply to Anthony Jones (:kentuckyfriedtakahe) from comment #5) > Async pan/zoom is currently being worked on and will affect the amount and > type of painting we do. It will likely result in less display list > processing but more painting. It may be useful to compare direct2d with > cairo. For the record, this was done, there's no significant difference between Direct2D or Cairo.

It seems to me like we ought to be able to paint more than one line of pixels at once given the way we now use the layer system in scrolling.

(In reply to David Baron [:dbaron] (don't cc:, use needinfo? instead) from comment #9) > It seems to me like we ought to be able to paint more than one line of > pixels at once given the way we now use the layer system in scrolling. That's not really how currently layout talks to the layers system as far as I know. It certainly could work that way by changing the visible region in steps rather than by single lines I'd say.

With APZC we should be able to do it all in the compositor with at most one content repaint.

Nick, can you get a profile here? Also, can you measure FPS during the scrolling of Wikipedia in the test? Taras says it looks like we're not hitting 60, and for a simple page like this we should be!

Taras: is this Metro or desktop browser? I guess it doesn't make a difference for layout, but it will be a big difference for gfx. Also, does this repro on Win 7?

(In reply to Nick Cameron [:nrc] from comment #13) > Taras: is this Metro or desktop browser? I guess it doesn't make a > difference for layout, but it will be a big difference for gfx. Also, does > this repro on Win 7? desktop.it should be the same on win7.

I never did get a chance to look into this properly, sorry. I have been profiling scrolling wikipedia a bit for my investigations into OMTC. On OMTC we are regressing a bit due to direct2d being awkward. But for main thread rendering scrolling is nearly all bound by layout (rather than gfx). I'm not sure if we can cache more in gfx to make scrolling more efficient, or if we should try to optimise layout.

This is probably worth re-testing with APZC.