This week's book giveaway is in the General Computing forum.
We're giving away four copies of Learning Regular Expressions and have Ben Forta on-line!
See this thread for details.
Win a copy of Learning Regular Expressions this week in the General Computing forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
  • Liutauras Vilda
  • Campbell Ritchie
  • Tim Cooke
  • Bear Bibeault
  • Devaka Cooray
  • Jeanne Boyarsky
  • Knute Snortum
  • Junilu Lacar
Saloon Keepers:
  • Tim Moores
  • Ganesh Patekar
  • Stephan van Hulst
  • Pete Letkeman
  • Carey Brown
  • Tim Holloway
  • Ron McLeod
  • Vijitha Kumara

Waiting the Event-Dispatch thread  RSS feed

Ranch Hand
Posts: 45
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I want to write a single threaded application with a GUI. I'm writing for a limited environment and context switches and synchronization are very expensive. I need to provide a little background before I get to my question.
I'm using just simple low level graphics calls and no widgets nor peer code. Given that I need to use one thread, and assuming it has a user interface, I will need to solely use the event-dispatch thread (I have no choice, it's automatically provided).
I understand that the event-dispatch thread basically just loops on an event-queue executing event listener and paint methods. Typically it's bad to have your GUI application do anything significant in code spawned from the event-dispatch thread (e.g. spawned from event listener or paint methods) since you can block the thread from executing subsequent events.
However, you can add your own Runnable events to the event-queue. If you keep these Runnable events granular enough, and schedule subsequent Runnable events from them, you'll not block the event-dispatch or paint calls (which will be interleaved).
For example, if I start by queuing Rendering Engine (my class for rendering the scene) and it calls repaint followed by scheduling the Interaction Engine (my class for handling user-events) and the user pressed a key sometime after I call repaint but before I schedule the Interaction Engine, the event-dispatch thread would execute the following events in order...
- canvas.paint
- listener.keyPressed
So all I have to do is break my logic up somewhat so that the last event that I schedule knows what to schedule next (I guess I'll make a scheduler for this).
I am going to have scheduled updates (i.e. I'll know in advance how long to wait before the next update) and unscheduled updates (i.e. a user event I want to react to). I want to avoid having the code thrash (i.e. effectively be a tight loop checking whether there's work to do).
In order to avoid the code thrashing, I want to wait the event-dispatch thread periodically. If the event-dispatch thread is waiting, then I can't react to user-events UNLESS there's some way to notify the event-dispatch thread to wake up. My question is, is there something that I can lock onto that will receive notifications when user-events are dispatched to the event-queue.
I don't think the event-dispatch thread thrashes so I'm assuming that it is waiting on something when it's not got something to do. I want to wait on the same object. I'm going to play around and try and grab the mutex for the event-queue in case the VM notifies this.
Anyone got any knowledge of this?
Regards and thanks for getting this far,
Paul Kelcey
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!