Jason Osgood <[EMAIL PROTECTED]> writes:
> I chatted with a former JavaSoft UI dude
Is it possible for you to chat with him in the future? It'd be great
if I could ask him a couple of questions.
> who shared with me his opinion that JDK's thread model for the AWT
> was suboptimum and has lots of synchronization issues.
He's correct -- however it's more of a JDK implementation issue rather
than a design issue. The exception is InputEvent, I could kill
whoever designed it.
> Soo... Now that this list is talking about AWT... a) I'm very
> interested in helping with the Java side.
You're more than welcome to start implementing pieces of the Java side
of the AWT -- implement a layout manager, or do whatever floats your
boat. Our current AWT work in GNU Classpath has been peer side only.
> b2) Evidently JDK's thread solution is suboptimum and I was curious
> if anyone knew what the issues are and more importantly has a good
> idea of what to do.
Yes. Events in Java are weird -- how they're dispatched, how they're
handled, how they're intercepted, how they can be consumed, how they
can be synthesized -- it's all rather harry and very tricky in places
-- especially for the peer code.
Here's quick a overview:
+----------------+
| AWT EventQueue |
+----------------+
(getNextEvent) / \ (postEvent)
/ \
+-----------------+ +-------------+
| Dispatch thread | | Peer thread |
+-----------------+ +-------------+
|
| ^
v | (send back to peer)
+-------------------------------+ |
| Send to destination component | |
+-------------------------------+ |
| |
| | ^
v | | (simulate event
+-------------------+ | | to peer widget)
| Send to listeners | | |
+-------------------+ / |
| / |
+----------------------------- |
|
+-------------------+ /
| Random Java code | (fire InputEvent) -----/
+-------------------+
The peer code runs on its thread, receiving events from the X server.
When an event is received, it's processed by the native widget, and
then forwarded to Java -- as a postEvent to the event queue.
Later on, a thread in Java-land reads the posted event, and sends it
down the hierarchy of listeners, if anyone is interested in it, and
finally ships it back to the peer (who generally ignores it).
Problem: ALL events are received by the C peer code and posted to the
EventQueue, even if *no one* on the Java side wants to receive the
event. Especially under X, this generates a lot of unnecessary
network traffic. Every time you move the cursor, an event is posted
to the EventQueue. Currently, a peer must provide the EventQueue with
ALL events that occur. When we write our implementation of the AWT,
we should tell the peers what events we're interested in receiving.
Such an addition would be trivial, and it would dramatically improve
performance.
Problem: In the JDK, there is only one thread that dispatches the
events and performs the Java callbacks. A more optimal solution would
be to have a pool of threads waiting at the EventQueue to handle
incoming events.
The exception to the above scenario of event handling in Java occurs
when an InputEvent is received by the peer code. The peer code
*intercepts* the event before it is sent to the native widget. It
then forwards the request over to the EventQueue, and waits for the
event to come back to the peer. When it comes back, if the event has
not been consumed (isConsumed() == false), then the event is sent to
the native widget. Such a scheme was implemented to allow various
random pieces of esoteric software to function "normally" -- GUI
builders are a good example. You can lay out a Button, and by
consuming the MOUSE_PRESSED event, you can keep the button from ever
becoming depressed. So when the user did click the Button, you could
move it around on the screen or something.
The ability to consume events means that events must go from C to Java
and then back to C before the native widget can process it!
Lots of important events can be consumed according to the Java spec --
any InputEvent. So we have, in theory, a round-trip occurring every
time you move the mouse pointer, click a button, hit a key, release a
key, enter a widget, etc. However, I don't buy into the theory that
everything should be consumable -- it would just make things too slow.
So, until I hear otherwise, things such as MouseMotion events will not
be consumable.
Simulating InputEvents can be done by creating an event and sending it
to the handleAWTEvent method of the peer. Yet more complexity. :)
That's quick overview of events in Java...
Happy Hacking.
--
Paul Fisher * [EMAIL PROTECTED]
