Olli Pettay [:smaug][bugs@pettay.fi] Reporter
	Description • 9 years ago

Scrolling is particularly bad with e10s+apz, but also with non-e10s/apz scrolling the top part of the page is very jank-y.

(about to do some profiling once I have up-to-date opt-build ready)

	Olli Pettay [:smaug][bugs@pettay.fi] Reporter
	Comment 1 • 9 years ago

>50% time is on X / pixman side (are we using X inefficiently?).

	Kartikaya Gupta (email:kats@mozilla.staktrace.com)
	Comment 2 • 9 years ago

Do you have a profile you can link/attach?

	Olli Pettay [:smaug][bugs@pettay.fi] Reporter
	Comment 4 • 9 years ago

These are both non-e10s/apz

	Olli Pettay [:smaug][bugs@pettay.fi] Reporter
	Comment 5 • 9 years ago

And gecko profiler results http://people.mozilla.org/~bgirard/cleopatra/#report=2409bb9fae377af4d67d011df3fcfbfa7aacf252

	Olli Pettay [:smaug][bugs@pettay.fi] Reporter
	Comment 6 • 9 years ago

This is all X and our use of X, but
nsWindow::GetClientOffset is oddly slow. Should we perhaps cache its value?

	Kartikaya Gupta (email:kats@mozilla.staktrace.com)
	Comment 7 • 9 years ago

If we can cache it that would probably help considering how big it is in the profiles. I don't know enough about the GTK APIs to know how we might clear the cache when it changes though. Karl, do you know?

	Markus Stange [:mstange]
	Comment 8 • 9 years ago

See bug 1077652 comment 58 and bug 1097114 (and bug 1128934 comment 3 for a different approach).

	Kartikaya Gupta (email:kats@mozilla.staktrace.com)
	Comment 9 • 9 years ago

Thanks! Removing ni since karlt has already explained this multiple times it seems :)

	Markus Stange [:mstange]
	Comment 10 • 9 years ago

There is something else going wrong on this page - we repaint the top strip of the header image on every refresh driver tick, and the whole header on every scroll. If I remove background-blend-mode: soft-light from the .page-header CSS rule, those repaints go away.

	Markus Stange [:mstange]
	Comment 11 • 9 years ago

I'll debug the invalidation bug.

	Markus Stange [:mstange]
	Comment 12 • 8 years ago

Do we still suffer from slow nsWindow::GetClientOffset?
It looks like the invalidation bug is gone, so even if we were still using xrender, we wouldn't flood the window server with painting any more, so a slow nsWindow::GetClientOffset probably wouldn't be noticeable on this page any more.

	Lee Salzman [:lsalzman]
	Comment 13 • 8 years ago

(In reply to Markus Stange [:mstange] from comment #12)
> Do we still suffer from slow nsWindow::GetClientOffset?
> It looks like the invalidation bug is gone, so even if we were still using
> xrender, we wouldn't flood the window server with painting any more, so a
> slow nsWindow::GetClientOffset probably wouldn't be noticeable on this page
> any more.

We fixed GetClientOffset so that it should now just access a member variable in nsWindow. Shouldn't cause any more traffic into GTK.

	Markus Stange [:mstange]
	Comment 14 • 8 years ago

Looks like this was fixed by bug 1196494 and by a blending / invalidation change.