Open Bug 804271 Opened 7 years ago Updated 6 years ago

Graphics jank, slow tab switch times while using social

Categories

(Core :: Graphics: Layers, defect)

x86_64
Windows 7
defect
Not set

Tracking

()

People

(Reporter: taras.mozilla, Unassigned)

References

Details

(Whiteboard: [Snappy:P1])

....D3D10::EndTransaction takes a long time with social on. Not sure why. http://people.mozilla.com/~bgirard/cleopatra/?report=ee60e06ee31346a692d28489e6267c8689b5e808
My tab-switch times are 1.5-2x slower when the social sidebar is shown
Summary: Graphics jank while using social → Graphics jank, slow tab switch times while using social
Whiteboard: [Snappy] → [Snappy:P1]
(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
(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.
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?
adding social crew to get this on their radar.
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.
Could this be caused by bug 805331?
(In reply to :Gavin Sharp (use gavin@gavinsharp.com 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.
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.
(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?
(In reply to :Gavin Sharp (use gavin@gavinsharp.com 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?
Depends on: 812652
(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...
Is it just running a lot of JS and hogging the event loop?
(In reply to :Gavin Sharp (use gavin@gavinsharp.com 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?
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.
You need to log in before you can comment on or make changes to this bug.