Vsync disabled even with only one window swapping |
||
Issue descriptionI ported the multi window force swap interval zero logic from Windows to Linux here. After that change, I've found that we end up with swap interval zero often with only one window displayed. I added a stack trace to ContextProviderCommandBuffer's ctor if it was for a native surface (surface_handle != gpu::kNullSurfaceHandle) and found that we create two context provider instances with view surfaces: #0 0x7f57bc7f67b7 base::debug::StackTrace::StackTrace() #1 0x7f57ba808bda ui::ContextProviderCommandBuffer::ContextProviderCommandBuffer() #2 0x7f57ba7edfbd (anonymous namespace)::CreateContextCommon() #3 0x7f57ba7ed337 content::GpuProcessTransportFactory::EstablishedGpuChannel() #4 0x7f57ba7efdae _ZN4base8internal13FunctorTraitsIMN7content26GpuProcessTransportFactoryEFvNS_7WeakPtrIN2ui10CompositorEEEbi13scoped_refptrIN3gpu14GpuChannelHostEEEvE6InvokeIRKNS4_IS3_EEJRKS7_RKbRKiSB_EEEvSD_OT_DpOT0_ #5 0x7f57ba7efd16 _ZN4base8internal7InvokerINS0_9BindStateIMN7content26GpuProcessTransportFactoryEFvNS_7WeakPtrIN2ui10CompositorEEEbi13scoped_refptrIN3gpu14GpuChannelHostEEEJNS5_IS4_EES8_biEEEFvSC_EE3RunEPNS0_13BindStateBaseEOSC_ #6 0x7f57ba5642e1 content::BrowserGpuChannelHostFactory::GpuChannelEstablished() #7 0x7f57ba56407e content::BrowserGpuChannelHostFactory::EstablishRequest::FinishOnMain() #8 0x7f57bc7f70d0 base::debug::TaskAnnotator::RunTask() #9 0x7f57bc81b36d base::MessageLoop::RunTask() #10 0x7f57bc81b6f8 base::MessageLoop::DeferOrRunPendingTask() #11 0x7f57bc81bc96 base::MessageLoop::DoWork() #12 0x7f57bc81d1ca base::(anonymous namespace)::WorkSourceDispatch() #13 0x7f57b4ead377 g_main_context_dispatch #14 0x7f57b4ead5e0 <unknown> #15 0x7f57b4ead68c g_main_context_iteration #16 0x7f57bc81d036 base::MessagePumpGlib::Run() #17 0x7f57bc81b097 base::MessageLoop::RunHandler() #18 0x7f57bc84338e base::RunLoop::Run() #19 0x55aef8c163e2 ChromeBrowserMainParts::MainMessageLoopRun() #20 0x7f57ba45acf2 content::BrowserMainLoop::RunMainMessageLoopParts() #21 0x7f57ba45d8ad content::BrowserMainRunnerImpl::Run() #22 0x7f57ba4563f8 content::BrowserMain() #23 0x7f57baac73e8 content::ContentMainRunnerImpl::Run() #24 0x7f57bccee675 service_manager::Main() #25 0x7f57baac6342 content::ContentMain() #26 0x55aef868a5f1 ChromeMain #27 0x7f57b21b83f1 __libc_start_main #28 0x55aef868a45f <unknown> #0 0x7f57bc7f67b7 base::debug::StackTrace::StackTrace() #1 0x7f57ba808bda ui::ContextProviderCommandBuffer::ContextProviderCommandBuffer() #2 0x7f57ba7edfbd (anonymous namespace)::CreateContextCommon() #3 0x7f57ba7ed337 content::GpuProcessTransportFactory::EstablishedGpuChannel() #4 0x7f57ba7efdae _ZN4base8internal13FunctorTraitsIMN7content26GpuProcessTransportFactoryEFvNS_7WeakPtrIN2ui10CompositorEEEbi13scoped_refptrIN3gpu14GpuChannelHostEEEvE6InvokeIRKNS4_IS3_EEJRKS7_RKbRKiSB_EEEvSD_OT_DpOT0_ #5 0x7f57ba7efd16 _ZN4base8internal7InvokerINS0_9BindStateIMN7content26GpuProcessTransportFactoryEFvNS_7WeakPtrIN2ui10CompositorEEEbi13scoped_refptrIN3gpu14GpuChannelHostEEEJNS5_IS4_EES8_biEEEFvSC_EE3RunEPNS0_13BindStateBaseEOSC_ #6 0x7f57ba564b48 content::BrowserGpuChannelHostFactory::EstablishGpuChannel() #7 0x7f57ba7ecc7f content::GpuProcessTransportFactory::CreateCompositorFrameSink() #8 0x7f57b90f172c ui::Compositor::RequestNewCompositorFrameSink() #9 0x7f57bc7f70d0 base::debug::TaskAnnotator::RunTask() #10 0x7f57bc81b36d base::MessageLoop::RunTask() #11 0x7f57bc81b6f8 base::MessageLoop::DeferOrRunPendingTask() #12 0x7f57bc81bc96 base::MessageLoop::DoWork() #13 0x7f57bc81cfd9 base::MessagePumpGlib::Run() #14 0x7f57bc81b097 base::MessageLoop::RunHandler() #15 0x7f57bc84338e base::RunLoop::Run() #16 0x55aef8c163e2 ChromeBrowserMainParts::MainMessageLoopRun() #17 0x7f57ba45acf2 content::BrowserMainLoop::RunMainMessageLoopParts() #18 0x7f57ba45d8ad content::BrowserMainRunnerImpl::Run() #19 0x7f57ba4563f8 content::BrowserMain() #20 0x7f57baac73e8 content::ContentMainRunnerImpl::Run() #21 0x7f57bccee675 service_manager::Main() #22 0x7f57baac6342 content::ContentMain() #23 0x55aef868a5f1 ChromeMain #24 0x7f57b21b83f1 __libc_start_main #25 0x55aef868a45f <unknown> I've also found that we swap two instances of GLSurfaceGLX: [10783:10783:0429/112922.125534:INFO:gl_surface_glx.cc(610)] GLSurfaceGLX::SwapBuffers 0x28f3dce92190 <swaps of above surface due to blinking cursor> <move the mouse over the most visited tabs tiles> <the second stack trace is emitted> [10783:10783:0429/112922.433965:INFO:gl_surface_glx.cc(610)] GLSurfaceGLX::SwapBuffers 0x28f3e005fe60 <no more swaps of the above surface> <swaps of original surface due to blinking cursor> Is this expected? I haven't verified this on Windows. The visual symptoms of this bug (tearing) are only visible on Linux without a compositing manager.
,
May 1 2017
2 view contexts is not expected to me
,
May 1 2017
Looks like we create a native widget for tooltips: [4432:4432:0501/144828.044721:INFO:compositor.cc(72)] #0 0x7ff3690f7bc7 base::debug::StackTrace::StackTrace() #1 0x7ff3659ef4db ui::Compositor::Compositor() #2 0x7ff365a78d2d aura::WindowTreeHost::CreateCompositor() #3 0x7ff365567dac views::DesktopWindowTreeHostX11::InitX11Window() #4 0x7ff36556715a views::DesktopWindowTreeHostX11::Init() #5 0x7ff36555a883 views::DesktopNativeWidgetAura::InitNativeWidget() #6 0x7ff3655430b0 views::Widget::Init() #7 0x7ff365553822 views::corewm::TooltipAura::SetText() #8 0x7ff3655552eb views::corewm::TooltipController::ShowTooltip() #9 0x7ff36917b7f7 base::Timer::RunScheduledTask() #10 0x7ff3690f84e0 base::debug::TaskAnnotator::RunTask() #11 0x7ff36911c76d base::MessageLoop::RunTask() #12 0x7ff36911caf8 base::MessageLoop::DeferOrRunPendingTask() #13 0x7ff36911d1bc base::MessageLoop::DoDelayedWork() #14 0x7ff36911e5f0 base::(anonymous namespace)::WorkSourceDispatch() #15 0x7ff3617b3e04 g_main_context_dispatch #16 0x7ff3617b4048 <unknown> #17 0x7ff3617b40ec g_main_context_iteration #18 0x7ff36911e436 base::MessagePumpGlib::Run() #19 0x7ff36911c497 base::MessageLoop::RunHandler() #20 0x7ff36914514e base::RunLoop::Run() #21 0x5581e125e3b2 ChromeBrowserMainParts::MainMessageLoopRun() #22 0x7ff366d59812 content::BrowserMainLoop::RunMainMessageLoopParts() #23 0x7ff366d5c3cd content::BrowserMainRunnerImpl::Run() #24 0x7ff366d54f08 content::BrowserMain() #25 0x7ff3673c66c8 content::ContentMainRunnerImpl::Run() #26 0x7ff3695ef615 service_manager::Main() #27 0x7ff3673c5622 content::ContentMain() #28 0x5581e0cd16c1 ChromeMain #29 0x7ff35edaaf45 __libc_start_main #30 0x5581e0cd152f <unknown> This is created the first time a tooltip is created. It's cached for later use. Still seems really heavyweight for a tooltip.
,
May 1 2017
Ah, its cuz tooltips are a separate native window, which means a separate compositor, because they are not clipped by the bounds of the browser window.
,
May 1 2017
On windows we have a way to make the status bubble use software compositing, which can reduce overhead - https://cs.chromium.org/chromium/src/ui/views/widget/widget.h?type=cs&q=force_software_compositing+package:%5Echromium$&l=295
,
May 1 2017
That would probably fix https://bugs.chromium.org/p/chromium/issues/detail?id=442111 too, and there's no reason to use GPU for the tooltip. That seems like a good idea here too.
,
May 1 2017
Aura windows forces software compositing for some widgets: https://cs.chromium.org/chromium/src/content/browser/compositor/gpu_process_transport_factory.cc?rcl=c9f5a36c6fc6af9039b086d08ea370e3cb575d03&l=296 It doesn't look like it's being used for tooltips but it's used in other places.
,
Jun 9 2017
sunnyps@, is this still P1? What are the next steps here?
,
Nov 3 2017
Friendly ping - sunnyps@, can you update the status and drop priority if we don't need to fix this soon? Thanks!
,
Nov 3 2017
thomasanderson@ made tooltips use software compositing (see issue 442111 ). So, this is not an issue any more. |
||
►
Sign in to add a comment |
||
Comment 1 by kbr@chromium.org
, May 1 2017Components: Internals>GPU>Internals