A different way to handle pulse timing
artem.ananiev at oracle.com
Tue Aug 6 07:51:57 PDT 2013
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
More information about the openjfx-dev