+++ This bug was initially created as a clone of Bug #1342209 +++ Copied the context from bug 1342209 comment 11. I have a windows 10 machine with Intel integrated Graphics. I could see a little bit scrolling speed difference between e10s and non-e10s FF for the link in comment 0. Steps to reproduce: 1. Load <https://www.blog.google/topics/journalism-news/expanding-fact-checking-google/>. 2. Scroll down to the middle. 3. Using the trackpad, scroll to the top really fast. This is the profile with e10s enabled. https://perfht.ml/2oYHd99 I found several composition took more than 10 ms and they were spent 60% composition time for GetDeviceRemovedReason inside CompositorD3D11::EndFrame(). CDevice::GetDeviceRemovedReason() mozilla::layers::CompositorD3D11::EndFrame() mozilla::layers::LayerManagerComposite::Render(mozilla::gfx::IntRegionTyped<mozilla::gfx::UnknownUnits> const &,mozilla::gfx::IntRegionTyped<mozilla::gfx::UnknownUnits> const &) LayerManagerComposite::EndFrame LayerManagerComposite::Render mozilla::layers::LayerManagerComposite::UpdateAndRender() mozilla::layers::LayerManagerComposite::EndTransaction(mozilla::TimeStamp const &,mozilla::layers::LayerManager::EndTransactionFlags) mozilla::layers::CompositorBridgeParent::CompositeToTarget(mozilla::gfx::DrawTarget *,mozilla::gfx::IntRectTyped<mozilla::gfx::UnknownUnits> const *) CompositorBridgeParent::Composite mozilla::layers::CompositorVsyncScheduler::Composite(mozilla::TimeStamp) mozilla::detail::RunnableMethodImpl<mozilla::layers::CompositorVsyncScheduler * const,void ( mozilla::layers::CompositorVsyncScheduler::*)(mozilla::TimeStamp),1,1,mozilla::TimeStamp>::Run()

Overall composition time are less than 16 ms and it's not obvious if users don't pay attention on the animation. Ehsan, do we need to set this bug as qf p1?

This should be a windows only problem unrelated to client storage.