Mechanism for determining UI Freeze in Timeline view impacting WPF Dispatcher Efficiency?

I love Timeline view.  I spend significant portions of every week tracking down performance problems, and Timeline view is my go-to tool.  However, I'm afraid it's misleading me a bit.

Timeline view is appearing to show me some inefficiency in the UI thread for our application - saying it's running for ~50% of the time and waiting ~50% of the time.  Given what I know about the code running at the time - this didn't really make sense to me.  We've got a bunch of background tasks that are completing, and when they complete, they post results to the UI thread.  The dispatcher queue should be full of work during the time that's reporting 50% waiting.  The operations posted to the UI thread are done via the WPF dispatcher, and in general, are done at DispatcherPriority.Background.  Here's a zoomed in view of what the UI thread looks like in the timeline view:

You can see that there's a period of work, followed by a period of rest. 

After spending some time reading through the Dispatcher code in ReferenceSource (I'm profiling a .NET Framework 4.6.2 desktop application), I think the reason for these gaps is because:

1. We are notified of work available in the dispatcher queue, and it is processed via ProcessQueue.
2. ProcessQueue pulls the operation out of the queue, and then requests that we process the next item in the queue, via CriticalRequestProcessing.
3. CriticalTestProcessing tests whether the operations is Foreground or Background - because the operations we're posting are at DispatcherPriority.Background (less than Loaded), we go down the RequestBackgroundProcessing path.
4. This is where I think the problem is.  In RequestBackgroundProcessing, they attempt to determine whether there is any input pending.  If there is input pending, they don't pull the next item from the queue until a timer has elapsed.

I can see this happening in the profile:

So, my guess is that the dotTrace Timeline profiler is posting some kind of input message to the application window to determine whether there's currently a "UI Freeze" (the purple bars at the top of the profile window).  If that's the case, those posted input messages that are being sent are causing significant (~40%) differences in the end to end time for some of our operations.

If dotTrace isn't faking input to the application under test - how is it determining whether there's a UI Freeze?  If this is a legitimate problem in my application, I'd like to know, because figuring it out could improve the runtime of some operations by nearly double...

Thanks for any information -

Nick