804271 - Graphics jank, slow tab switch times while using social

Status: RESOLVED INVALID

(Core :: Graphics: Layers, defect)

Description

[(dormant account)]

....D3D10::EndTransaction takes a long time with social on. Not sure why. http://people.mozilla.com/~bgirard/cleopatra/?report=ee60e06ee31346a692d28489e6267c8689b5e808

Comment 1

[(dormant account)]

My tab-switch times are 1.5-2x slower when the social sidebar is shown

Comment 2

[(dormant account)]

(In reply to Taras Glek (:taras) from comment #1)
> My tab-switch times are 1.5-2x slower when the social sidebar is shown

according to FX_TAB_SWITCH_TOTAL_MS

Comment 3

[(dormant account)]

(In reply to Taras Glek (:taras) from comment #1)
> My tab-switch times are 1.5-2x slower when the social sidebar is shown

According to paint_flashing, the sidebar is not being redrawn every time.

Comment 4

[(dormant account)]

I see nsCSSRendering::PaintBackground responsible for 7% of the samples while holding down ctrl+tab with social sidebar on, it doesn't showup without. Maybe we are processing social layout on every tab switch?

Comment 5

[David Ascher (:davida)]

adding social crew to get this on their radar.

Comment 6

[Mark Hammond [:markh] [:mhammond]]

See also bug 801488 - that implies we are doing extra work when resizing the app window, even though that resize generally doesn't change the size of the sidebar, just the app content area.

Comment 7

[:Gavin Sharp [email: [e-mail]]]

Could this be caused by bug 805331?

Comment 8

[Robert O'Callahan (:roc) (email my personal email if necessary)]

(In reply to :Gavin Sharp (use [e-mail] for email) from comment #7)
> Could this be caused by bug 805331?

It could be related, but the patches in bug 805331 won't fix it.

Comment 9

[Robert O'Callahan (:roc) (email my personal email if necessary)]

It looks like we're just doing too much painting. Not sure why it should affect tab switching though, since we repaint tabs then anyway.

Comment 10

[(dormant account)]

http://people.mozilla.com/~bgirard/cleopatra/#report=8213fa38182f552528fe01f235c91dbe4e5019f9&javascriptOnly=true&selection=%255B%2522%28root%29%2522%252C%2522messageHandler%28%29%2520%2540%2520FrameWorker.jsm%253A390%2522%252C%2522_messageHandler%28%29%2520%2540%2520FrameWorker.jsm%253A347%2522%252C%2522fw_AbstractPort_onmessage%28%29%2520%2540%2520MessagePortBase.jsm%253A41%2522%255D this profile contains a large amount of social activity coming from FrameWorker.jsm

Comment 11

[:Gavin Sharp [email: [e-mail]]]

(In reply to Taras Glek (:taras) from comment #10)
> http://people.mozilla.com/~bgirard/cleopatra/
> #report=8213fa38182f552528fe01f235c91dbe4e5019f9&javascriptOnly=true&selectio
> n=%255B%2522%28root%29%2522%252C%2522messageHandler%28%29%2520%2540%2520Frame
> Worker.
> jsm%253A390%2522%252C%2522_messageHandler%28%29%2520%2540%2520FrameWorker.
> jsm%253A347%2522%252C%2522fw_AbstractPort_onmessage%28%29%2520%2540%2520Messa
> gePortBase.jsm%253A41%2522%255D this profile contains a large amount of
> social activity coming from FrameWorker.jsm

Most of the time spent under FrameWorker.jsm is in Facebook script - can you file a new bug in Firefox::SocialAPI: Providers so that some Facebook people can look into it?

Comment 12

[(dormant account)]

(In reply to :Gavin Sharp (use [e-mail] for email) from comment #11)
> (In reply to Taras Glek (:taras) from comment #10)
> > http://people.mozilla.com/~bgirard/cleopatra/
> > #report=8213fa38182f552528fe01f235c91dbe4e5019f9&javascriptOnly=true&selectio
> > n=%255B%2522%28root%29%2522%252C%2522messageHandler%28%29%2520%2540%2520Frame
> > Worker.
> > jsm%253A390%2522%252C%2522_messageHandler%28%29%2520%2540%2520FrameWorker.
> > jsm%253A347%2522%252C%2522fw_AbstractPort_onmessage%28%29%2520%2540%2520Messa
> > gePortBase.jsm%253A41%2522%255D this profile contains a large amount of
> > social activity coming from FrameWorker.jsm
> 

What does the frameworker provide? shouldn't clients be doing expensive processing in a worker thread?
> Most of the time spent under FrameWorker.jsm is in Facebook script - can you
> file a new bug in Firefox::SocialAPI: Providers so that some Facebook people
> can look into it?

Comment 13

[:Gavin Sharp [email: [e-mail]]]

(In reply to Taras Glek (:taras) from comment #12)
> What does the frameworker provide? shouldn't clients be doing expensive
> processing in a worker thread?

It's a re-implementation of a SharedWorker using a JS sandbox on the main thread. If we properly supported real SharedWorkers (bug 643325) we'd be in a much better situation...

Comment 14

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

Is it just running a lot of JS and hogging the event loop?

Comment 15

[:Gavin Sharp [email: [e-mail]]]

Yes.

Comment 16

[(dormant account)]

(In reply to :Gavin Sharp (use [e-mail] for email) from comment #13)
> (In reply to Taras Glek (:taras) from comment #12)
> > What does the frameworker provide? shouldn't clients be doing expensive
> > processing in a worker thread?
> 
> It's a re-implementation of a SharedWorker using a JS sandbox on the main
> thread. If we properly supported real SharedWorkers (bug 643325) we'd be in
> a much better situation...

Was SharedWorker ever considered a blocker for social? Is it something that can be retrofitted in subsequent releases?

Comment 17

[:Gavin Sharp [email: [e-mail]]]

I think it was too large of an undertaking to block social, and we already had a  workable (less optimal) alternative. The plan has always been to switch to a SharedWorker when possible.

Comment 18

[Gregory Pappas [:gregp]]

Social sidebar no longer exists.