Поток пользовательского интерфейса WPF на мгновение останавливается, когда событие mouseup вызывает анимацию

Question

У меня есть приложение WPF, которое постоянно анимируется. Одно взаимодействие (mouseup) и анимация в частности, кажется, замораживают поток пользовательского интерфейса на достаточно долгое время, чтобы быть очень заметным.

Concurrency Visualizer показывает, что мой поток пользовательского интерфейса заблокирован на 300 - 500 мс. Он также показывает стек, пока он заблокирован, и стек разблокировки:

Стек основного потока в замороженном состоянии :
Категория = Синхронизация
Задержка = 495,2472 мс

ntoskrnl.exe!SwapContext_PatchXRstor
ntoskrnl.exe!KiSwapContext
ntoskrnl.exe!KiCommitThreadWait
ntoskrnl.exe!KeWaitForSingleObject
ntoskrnl.exe!NtWaitForSingleObject
ntoskrnl.exe!KiSystemServiceCopyEnd
ntdll.dll!NtWaitForSingleObject
kernelbase.dll!WaitForSingleObjectEx
wpfgfx_v0400.dll!CMilConnection::SynchronizeChannel
wpfgfx_v0400.dll!CMilChannel::SyncFlush
wpfgfx_v0400.dll!MilComposition_SyncFlush
clr.dll!DoNDirectCallWorker
presentationcore.dll!System.Windows.Media.Composition.DUCE+Channel.**SyncFlush**
presentationcore.dll!System.Windows.Media.MediaContext.NotifyChannelMessage
presentationcore.dll!System.Windows.Media.MediaContextNotificationWindow.MessageFilter
windowsbase.dll!MS.Win32.HwndWrapper.WndProc
windowsbase.dll!MS.Win32.HwndSubclass.DispatcherCallbackOperation
windowsbase.dll!System.Windows.Threading.ExceptionWrapper.InternalRealCall
windowsbase.dll!MS.Internal.Threading.ExceptionFilterHelper.TryCatchWhen
windowsbase.dll!System.Windows.Threading.Dispatcher.WrappedInvoke
windowsbase.dll!System.Windows.Threading.Dispatcher.InvokeImpl
windowsbase.dll!MS.Win32.HwndSubclass.SubclassWndProc
windowsbase.dll!dynamicClass.IL_STUB_ReversePInvoke
clr.dll!UMThunkStubAMD64
user32.dll!UserCallWinProcCheckWow
user32.dll!DispatchMessageWorker
clr.dll!DoNDirectCall__PatchGetThreadCall
windowsbase.dll!dynamicClass.IL_STUB_PInvoke
windowsbase.dll!System.Windows.Threading.Dispatcher.PushFrameImpl
presentationframework.dll!System.Windows.Application.RunInternal
presentationframework.dll!System.Windows.Application.Run
xqstream.windows.exe!IQ.IR.Stream.WPF.App.Main

Стек разблокировки:

ntoskrnl.exe! ?? ?? ::FNODOBFM::`string'
ntoskrnl.exe!NtSetEvent
ntoskrnl.exe!KiSystemServiceCopyEnd
ntdll.dll!ZwSetEvent
kernelbase.dll!SetEvent
wpfgfx_v0400.dll!CMilConnection::PostMessageToClient
wpfgfx_v0400.dll!CMilServerChannel::SignalFinishedFlush
wpfgfx_v0400.dll!CComposition::FlushChannels
wpfgfx_v0400.dll!CPartitionThread::RenderPartition
wpfgfx_v0400.dll!CPartitionThread::Run
wpfgfx_v0400.dll!CPartitionThread::ThreadMain

Основной поток ожидает в фоновом потоке. Этот фоновый поток делает несколько вещей, но этот стек занимает ~ 3/4 времени:

Самая большая задача цепочки: Категория = I / O
Задержка = 347,5122 мс

ntoskrnl.exe!SwapContext_PatchXRstor
ntoskrnl.exe!KiSwapContext
ntoskrnl.exe!KiCommitThreadWait
ntoskrnl.exe!KeWaitForSingleObject
dxgmms1.sys!VIDMM_GLOBAL::CloseOneAllocation
dxgmms1.sys!VidMmCloseAllocation
dxgkrnl.sys!DXGDEVICE::DestroyAllocations
dxgkrnl.sys!DXGDEVICE::ProcessTerminationList
dxgkrnl.sys!DXGDEVICE::TerminateAllocations
dxgkrnl.sys!DXGDEVICE::DestroyAllocation
dxgkrnl.sys!DxgkDestroyAllocation
win32k.sys!NtGdiDdDDIDestroyAllocation
ntoskrnl.exe!KiSystemServiceCopyEnd
gdi32.dll!ZwGdiDdDDIDestroyAllocation
d3d9.dll!DeallocateCB
dlumd64.dll![dlumd64.dll]
nvd3dumx.dll![nvd3dumx.dll]
nvd3dumx.dll![nvd3dumx.dll]
nvd3dumx.dll![nvd3dumx.dll]
nvd3dumx.dll![nvd3dumx.dll]
nvd3dumx.dll![nvd3dumx.dll]
nvd3dumx.dll![nvd3dumx.dll]
nvd3dumx.dll![nvd3dumx.dll]
nvd3dumx.dll![nvd3dumx.dll]
dlumd64.dll![dlumd64.dll]
dlumd64.dll![dlumd64.dll]
d3d9.dll!DdBltLH
d3d9.dll!CSwapChain::PresentMain
d3d9.dll!CSwapChain::Present
wpfgfx_v0400.dll!CD3DDeviceLevel1::PresentWithD3D
wpfgfx_v0400.dll!CD3DDeviceLevel1::Present
wpfgfx_v0400.dll!CHwDisplayRenderTarget::PresentInternal
wpfgfx_v0400.dll!CHwDisplayRenderTarget::Present
wpfgfx_v0400.dll!CHwHWNDRenderTarget::Present
wpfgfx_v0400.dll!CDesktopRenderTarget::Present
wpfgfx_v0400.dll!CDesktopHWNDRenderTarget::Present
wpfgfx_v0400.dll!CSlaveHWndRenderTarget::Present
wpfgfx_v0400.dll!CRenderTargetManager::Present
wpfgfx_v0400.dll!CComposition::Present
wpfgfx_v0400.dll!CPartitionThread::PresentPartition
wpfgfx_v0400.dll!CPartitionThread::Run
wpfgfx_v0400.dll!CPartitionThread::ThreadMain

Я прочитал, что SyncFlush () вызывается после нескольких функций MilCore и, по-видимому, вызывает немедленную обработку изменений, которые были отправлены (благодарность Ray Burns).

Я бы хотел избавиться от этого замораживания, но я также надеюсь лучше понять, что делает WPF в этой ситуации, чтобы я мог построить лучшую ментальную модель работы WPF.

Answer 1

Из следов стека вперед и назад очевидно, что основной поток ожидает чего-то для полной очистки. Я понятия не имею, что такое SyncFlush или как вы обойдете его.

Если посмотреть на длинную трассировку стека ввода-вывода, возможно, проблема в драйвере Nvidia. WPF (wpfgfx_v0400) обращается к DirectX 9 (d3d9), который обращается к драйверу Nvidia (nvd3dumx).

Теперь возможно, что все платформы ведут себя должным образом и делают то, что им говорит ваш код. Также возможно, что в WPF, DirectX 9 или драйвере Nvidia может быть ошибка. Хотя в большинстве случаев проблема связана с вызывающим кодом.

Я предполагаю, что это приложение в качестве обработчика событий мыши. В этом случае наиболее вероятным источником проблемы с производительностью будет рассмотрение того, что это делает (или как это влияет на анимацию).

Answer 2

Когда ваш поток пользовательского интерфейса блокирует, обычно это происходит потому, что некоторая операция, которую вы выполняете над событием, не выполняется в его собственном потоке. Я бы сказал, чтобы проверить событие mouseup для длительной операции, которая может быть перенесена в фоновый поток, и позволить потоку пользовательского интерфейса быть свободным для отправки других событий.

Трассировка гигантского стека практически бесполезна для определения вашей истинной проблемы.