From 60fps to 10fps or so.

Is OMTC on the Mac under a pref right now?

Yes.

To be clear, the pref exists, but it's enabled by default on trunk and aurora.

What's the pref and what's the actual site for fishie?

(In reply to Milan Sreckovic [:milan] from comment #4) > What's the pref and what's the actual site for fishie? layers.offmainthreadcomposition.enabled http://ie.microsoft.com/testdrive/Performance/FishIETank/Default.html

I get ~ 50fps on the nightly, 10.8.

How many fish etc? I'm getting ~40fps with a debug build. Recent-ish m-c clone, 10.8

With 100 fish that is.

Oops, had SkiaGL enabled. 20fps.

I'm on 10.7 and get 5fps with 20 fish

I can see a few issues here, don't think they really explain a regression of the magnitude you're seeing though. 1a) Instead of sharing the canvas backing surface across IPC, we create a separate surface for sharing and make a copy every frame. 1b) We upload from our dedicated IPC surface while blocking the main thread, even though we wouldn't be writing into it. I think we need to fix either a or b. Changing both would cause race conditions. 2) We recreate our TextureImageTextureHostOGL every frame. http://mxr.mozilla.org/mozilla-central/source/gfx/layers/composite/ImageHost.cpp#34 mTextureHost->GetBuffer() is always false for single-buffered texture hosts. Once again, this happens while blocking the main thread, and seems to be kinda expensive. It would be nice if time spent in ClientLayerManager::ForwardTransaction could be split into time waiting for the other thread to start processing the transaction (waiting for the previous composite to finish), and time spent while actually processing it.

Fix for problem 2.

(In reply to Matt Woodrow (:mattwoodrow) from comment #11) > 1b) We upload from our dedicated IPC surface while blocking the main thread, > even though we wouldn't be writing into it. In bug 858914 I changed this (not landed yet): ShmemTextureHost and MemoryTextureHost now upload outside of the transaction (when Lock is called, only if the content of the shared data has changed).

Comment on attachment 769295 [details] [diff] [review] Check if the TextureHost is suitable rather than recreating it Review of attachment 769295 [details] [diff] [review]: ----------------------------------------------------------------- I am not too far from having the texture client/host rewrite ready (bug 858914). At this point I mostly need to adapt the D3D and basic backends to the new stuff. This patch doesn't fit in the new system because the problem it solves doesn't exist in the new system (we only create a texture host when we create a texture client). Since we are at the beginning of a cycle I would prefer just finishing bug 858914 and landing it, rather than having a temporary solution that will be removed by bug 858914 in the same cycle. Are you okay with that?

(In reply to Nicolas Silva [:nical] from comment #14) > > I am not too far from having the texture client/host rewrite ready (bug > 858914). At this point I mostly need to adapt the D3D and basic backends to > the new stuff. This patch doesn't fit in the new system because the problem > it solves doesn't exist in the new system (we only create a texture host > when we create a texture client). Since we are at the beginning of a cycle I > would prefer just finishing bug 858914 and landing it, rather than having a > temporary solution that will be removed by bug 858914 in the same cycle. > Are you okay with that? That's totally fine with me. Let me know if there's anything I can do to help with that bug too.

(In reply to Matt Woodrow (:mattwoodrow) from comment #15) > Let me know if there's anything I can do to help with that bug too. I could use some feedbacks/pre-review (the patch has gotten big so I'll have to break reviews between several people and you'll most likely will have the pleasure to review parts of it (sorry :p)). Once the big initial patch lands we'll have to convert all layer types to use the new texture stuff (right now I implemented it only for image which is probably the most complicated because of the amount of texture types to support and because of async-video), and this will be easier to do in parallel.

Given OMTC is disabled on FX24 untracking this.

I can confirm this bug. When I use Firefox 31 (aurora) and have set 20 fishes I get 40 fps and the count is not steady. If I use same test in safari 7 I get 60 fps. It is significant difference. When I set count of fishes to 1000, browser is totaly stucked and it is not usable. The same test in safari 7 - browser ok and 60 fps without any problem.

Could you attach a profile?

Do you mean whole directory with files?

(In reply to Michal K from comment #20) > Do you mean whole directory with files? Directory called "ehhhxo6b.default" ?

I tested the problem in the latest Firefox Nightly (E10s) 2015-05-21 and the problem is gone. I have 100 fishes and 50 - 60 fps.

Per comment 22