MIDP Event Delivery Mechanism

Print-friendly Version

Question

Do threads calling the event delivery mechanism go into a wait pool?

I've got a question about the event-delivery mechanism in MIDP. According to the specification, the methods are called serially, that is, one after the other, with events "queueing up" to be dealt with. Does this mean that the threads calling the event delivery methods go into a wait pool until the previous method has returned? If so, is there a limit to how many events can be waiting? The pointerDragged method, for example, can generate 100 events/second. How is it all implemented?

Tip

There is actually just one thread servicing events. This is the "main" or "event" thread for the application. All event callbacks (calls to CommandListener implementations or the event methods of Canvas) are done from this thread. That's why it's important to respond quickly to the event and do long operations on separate threads. After an event callback returns, the system goes back to the event queue and waits for another event to arrive, or else the system takes the next event that's sitting there and acts on it. A lot of the events actually get handled by the system, of course. Pointer and paint events are usually treated a bit differently than the other events. The system will "coalesce" these events into single events. In other words, if the system is waiting to deliver a pointer drag event and the user drags the pointer some more, the system will simply adjust the values in the queued event accordingly. Otherwise the application would be flooded with pointer events. Note that this coalescing mostly happens at the operating system level -- you get the same behavior in a Palm OS application written in C, for example.

Follow-up question: But if the coalescing applies to paint methods too, what happens to the data? With pointerDragged events, the most recent coordinates can be seen as the most relevant and therefore override any previous ones. With paint methods though (and here, I'm perhaps betraying my ignorance), some invocations would update different parts of the screen than others. Would the older invocations be superseded by the more recent ones?

Follow-up tip: Paint events are coalesced by taking the union of the paint are as, which is generalized to mean the minimal rectangle that contains the entire set of paint areas. And yes, this can lead to repainting parts of the screen that don't need to be repainted. Implementations that support double-buffering (painting to an off-screen area and then copying the resulting bitmap directly onto the screen in a single operation) minimize the flashing caused by excessive repainting.

Note, however, that paint coalescing doesn't have to take place -- it really depends on the implementation. The implementation could choose to keep individual paint events as they are. However, given the fact that many applications just blindly repaint the entire screen it's usually better for coalescing to occur. There are always tradeoffs....

BTW, none of this is really specific to MIDP. Any event-based GUI system has the same issues and does similar things. Some implementations actually coalesce paint events into true unions, that is, non-rectangular paint areas. AWT in J2SE 1.3 now does this, for example, see http://java.sun.com/j2se/1.3/docs/guide/awt/ for details.

Acknowledgments

Many thanks to Eric Giguere for contributing to this answer.

		Note: If you have a question to which you need an answer, try the Mobility Forums. You can read through the existing topics or register for your free Sun Developer Network membership and post new messages or threads. For more information, go to the Why Register page.