A different way to handle pulse timing

[Scott Palmer]

On 2013-08-06, at 9:10 AM, Artem Ananiev <artem.ananiev at oracle.com> wrote:

> 
> On 8/5/2013 10:26 PM, Richard Bair wrote:
>> 
>> In this proposal, we also would be putting the next pulse on the end
>> of the queue, so it is impossible to starve input events.
> 
> Putting the next pulse on the end of the queue is surprisingly difficult task, at least on Windows. If we use standard APIs provided by the platform, PostMessage() and SendMessage(), events are always put to the head of the queue. If we use timer events, they are of the lowest priority, so we'll have "paint starvation" instead of "input events starvation".

If the OS message queue is fundamentally broken (i.e. it does not behave like a queue), can all this be done on a proper queue that you have control over?
I.e. in the OS-specific message loop, just move the messages to a more reasonably behaved queue.  Posting a request to process a pulse would simply queue the operation on the well behaved queue and not use the OS PostMessage or SendMessage mechanism at all.  I admit to not knowing enough about Windows message processing to know if that even makes sense.
(Windows seriously doesn't have a mechanism to put something on the tail end of the message queue? Wow, don't they understand how a "queue" is supposed to work?)


Scott