Is it possible to run a method with Idle priority on the DispatcherQueue?

[aquinn39]

In UWP, you could use Dispatcher.RunIdleAsync to run a method at Idle priority. In DispatcherQueue, no such method exists. DispatcherQueue only has TryEnque, which uses DispatcherQueuePriority, which only has 3 possible values; Low, Normal and High - there is no Idle priority, which is lower than the Low priority. Does anyone know if it is possible to run a method on the DispatcherQueue at Idle priority or at least a priority that is lower than the render priority, so that the method runs after all UI has been updated?

[DarranRowe]

First, the documentation for CoreDispatcher.RunIdleAsync states that it actually runs things at CoreDispatcherPriority.Low priority. Interestingly, by the description given, this actually seems to be higher priority than DispatcherQueuePriority.Low priority. What's more, the description really makes me feel that CoreDispatcherPriority.Idle priority is equivalent to DispatcherQueuePriority.Low priority.
Well, the other wrinkle here is that when running as in a desktop environment, you can't get away from the message queue, and that has some major restrictions on when system triggered drawing occurs.
One important thing to remember is that the DispatcherQueue is implemented in terms of the Windows message queue. It should also use a message only window to do the synchronisation. This means that the dispatcher queue will be subject to the same priorities as the rest of the message queue, and not all events will come in via the dispatcher queue.
Drawing will be triggered when GetMessage receives a WM_PAINT message. If you peel back all of the layers, this is what even WinUI 3 will look for when it comes to drawing. Even other desktop applications that use the dispatcher queue will have this same message to trigger drawing. Even Windows Forms and WPF rely on this message to know when to draw.
As the remarks section for GetMessage states, WM_PAINT is an extremely low priority message. This message is only received if there is nothing else available besides timer related activities. This is where it is questionable whether even an "idle" priority could come after the drawing without some extraordinary effort to monitor the dispatcher queue thread to be sure that it is blocked.