On 8/6/2013 6:07 PM, Scott Palmer wrote:
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 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
