A different way to handle pulse timing

[Artem Ananiev]

On 8/6/2013 6:07 PM, Scott Palmer wrote:
>
> 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 wouldn't say it's broken :) It's implemented this way by design. BTW, 
as far as I know, Mac OS X is similar to Windows wrt event handling: all 
the selectors (correspond to PostMessage() and SendMessage()) are 
processed before input events.

> 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.

What you describe is close to how JavaFX is implemented on embedded 
platforms. See Lens code in Glass for details. We do this, because on 
that platforms there is virtually no native event queue, so we have our 
own. However, on platforms like Windows or Mac OS X, we have to use 
native event queues, otherwise JavaFX apps won't be good citizens there.

This is what we have in AWT/Swing, where a native event queue is 
separate from Java event queue. I can't say the exact number of minor 
(e.g. sluggish window resizing), major (dragndrop not working), and even 
fatal (JVM crashes) issues we fixed in AWT, that were caused by this 
architecture with 2 queues, but believe me this number is huge.

> (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?)

Why do you think it must be a queue? :) It can be a queue, but it can be 
something more complex as well. And yes, there is no easy way to put an 
event to the tail of the queue on Windows. What we can do is to put 
events to the queue with PostMessage/SendMessage, but dequeue them in 
different order. We prototyped that in the past, but didn't find it 
acceptable.

Thanks,

Artem

> Scott