On 2013-08-06, at 9:10 AM, Artem Ananiev <artem.anan...@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
