AWT thread scheduling?

I've had this problem several times now and I wonder what can be done about it. The general pattern of it is:

f = new Frame();
...
f.setVisible();
computesomethingtorenderinframe();
// only here the frame is refreshed

in the mean time the window sits there unrefreshed. It seems like the awt thread only wakes up (and calls paint() on its components) when all other threads have stopped computing? How do I get around this? I tried lowering the priority, yielding and sleeping, or manually calling repaint() but nothing helps. I'd like to understand how the AWT thread works in terms of scheduling and how to force it to wake up.
AardappelAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

imladrisCommented:
Well, mister potatoe,

I ran into a similar situation, and resolved it. It seems like repainting should be able to go on in "parallel" to the subsequent computing, but the JVM proffers few guarantees on the timing of such things. I have a program that must load a bunch of data over the network, and I wished to show its progress as it was loading, but before it was fully operational. The mechanism I used is to call the show method for the frame, then return.
In the paint method I check whether the display has been initialized yet. If not, I paint the loading display and post an event which will be caught elsewhere to start the actual loading. The loading calls a method which changes a page number for the display and when it is finished the functioning display is painted.
So there is a three state variable in paint: uninitialized, loading, and regular. During loading, whenever the page number needs changing a method is called that changes the page number variable and issues a repaint request. When loading is done, the state variable is changed, and another repaint issued.
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
heyhey_Commented:
just a note: I hope that you don't call this code
computesomethingtorenderinframe();

from some eventhandler method :) (or some paint() method) - this way you effectively block the AWT Thread.
0
AardappelAuthor Commented:
Like heyhey notes, moving it to paint is not going to solve the problem. It seems there is not any one spot where I can spend time computing without AWT blocking, not even in a seperate thread: AWT only kicks in when the rest of the system is idle.

Even worse, it is not always possible to encapsulate "whatever happens after .show()" such that it can be conveniently called from paint(), in my case opening the window is called from some place which then afterwards does some computation, and spread out over multiple threads as well. I can't somehow freeze the state of computation of all these threads and functions and then wake em up again from paint().

I'll give you some points anyway for your answer but sadly it doesn't solve it for me.
0
Keep up with what's happening at Experts Exchange!

Sign up to receive Decoded, a new monthly digest with product updates, feature release info, continuing education opportunities, and more.

heyhey_Commented:
if you have a good designb (based on message notification, not direct method calling) it should be possible to make exaustive computations without blocking the AWT threads (all computations in separate Threads).

btw. I've never experienced situations where 'AWT only kicks in when the rest of the system is idle.' - what's your OS / JDK version ?

we can't help without knowning more details (even better - sample code) about your design.
0
AardappelAuthor Commented:
windows95 r1, jbuilder 2/1.1.6, 1.2.x all give the same results.

providing code is going to be difficult, as the code that opens the Frame is being called from compiled code, i.e. I generate bytecodes from a totally different language and then run it using a classloader. Ican only give the general structure of it which I did above.

Thanks for the help though, I will try some stuff by launching even more threads, see if that helps.
0
imladrisCommented:
Note that I proposed that you POST an event from the paint method, not call something. Yes, as long as you have the system thread (the main thread of control) tied up, AWT threads will often be sluggish. My structure also returns, after the show, and then doesn't start the loading (which would be computation in your case), until after the paint is done. To get a responsive display in GUI systems in general you have to keep giving control back to the system (or processing messages). Rather than trying to run more threads, I would consider whether the computation can be broken into pieces.
0
AardappelAuthor Commented:
Yeah thanks that's a good trick to use. But like I said above, you aren't always able to structure a program at will, i.e. have it continue from somewhere else. In my case I have no choice.
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Java

From novice to tech pro — start learning today.