On 8/6/13 Aug 6, 10:07 AM, 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.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?)
This is what Glass/Lens does - the user event thread is all in Java. But then -
we also don't have to deal with any pesky native window managers :-)
Lens input events are taken from as close as we have to a native event loop (on
an input thread) and posted to the java based user event thread, just like any
other Application.InvokeLater (first in, first out queue). This also saves Lens
a bit of JNI handling as most user (non input events) never leave java this way.
Dave
Scott
--
David Hill <david.h...@oracle.com>
Java Embedded Development
"Sometimes the questions are complicated and the answers are simple."
-- Dr. Seuss (1904 - 1991)
