Nathan Meyers wrote:
> Ted Neward wrote:
> > Because Swing is a fully lightweight library, it can't rely on any of the
> > operating-system-specific constructs underneath the JVM to more efficiently
> > make use of the CPU. Instead, it spins off a daemon thread to (basically)
> > poll the OS for the mouse position and information and broadcast that
> > information to the Swing JComponents under the mouse pointer at that
> > moment.
>
> This sounds suspicious. Is this conjecture or based on analyzing the Swing code?
> There's always an AWT window under a top-level Swing window, and I would expect
> Swing to be using AWT events to be tracking input devices.
>
> Not that there aren't a lot of CPU-sucking details buried in Swing (or
> lightweight components in general)... I just question whether this is one of
> them.
>
As a member of the unfortunate cwrod who spends his life in the bowles of swing I
can
say this is not true.
What is probaly happing is there is some code in the demo which responds to and
event and then
generates and event ...
It may be the blinking text cursor but mine never shows up anyway and I think its
on a timer.
But I do see a lot of gui code wich generates event loops by accident.
And I write my own share : )
Often when I've had a gui app eat cpu sitting thre its becuase of a event loop.
I wish java soft would provide a simple debug switch for the EventLoop
heres what I do
take the instance and event class as args
Toolkit.getDefaultToolkit().getSystemEventQueue().debug( myFrame,
MouseEvent.class ); //add more agres if needed like a type for mouse etc
You coud do it external using peekEvent but I'm lazy. I just add it to a working
copy.
The nice thing is when I move out of debug nothing compiles till I remove or
comment out the debug code
keeps it out of production.
You can figure out what debug does.
Mike
----------------------------------------------------------------------
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
