[EMAIL PROTECTED] wrote: > I'm starting think my problem is knowing what solution applies to my > situation. There are plenty of solutions for handling long-running tasks in > Swing. (SwingWorker, etc.) There are solutions for double buffering for > animations (BufferStrategy). But, I don't think either of those apply to > long-running rendering tasks. > > Maybe a solution to that would be to drip-feed little subtasks onto the event > queue such that there is only one rendering task on the queue at a time and > user events will be interleaved in the queue between rendering tasks. > > Any other ideas or examples for maintaining a responsive UI in the presence > of long-running rendering tasks? > > Thanks, > > -chris
For complex paragraph layout tasks, the problem I had was to redo the layout in response to changes in the size of the display panel: to layout with wider of narrower line widths. Layout takes some time, so I am currently trying the following. In the panel (and in the EDT) capture the resize information, storing the latest size, and trying to start a worker. If a worker is already active, do nothing. Otherwise, start a size monitoring worker. The size monitoring worker in turn invokes another worker, whose job is to perform the layout. It creates the layout worker, triggers it with execute(), then blocks on a get() from the same worker. The doInBackground method returns an object representing the laid out paragraph. The done() method calls repaint, which collects the layout data and paints it, according to the size of the panel when the task started. Meanwhile, the size monitoring worker has returned from the get(), and can now check to see whether another size change has occurred. If so, it repeats the cycle of creating a layout worker. If not, it terminates, and the system waits on another size change event. It may seem that the size monitoring worker is redundant, but I found that it neatly separated the phases. One of the problems, I think, was that the actual repaint() takes some time itself. Performing the repaint in the done() method of layout worker seems to work, but ideally, I would like the size monitoring worker to wait until the repaint was finished before starting another layout worker, but I can't see an easy way to do that, while preserving the nice blocking characteristics of the get() method. It's a messy explanation, I know, and it was developed by trial and error. If you need anything clarified, let me know. -- Peter B. West <http://cv.pbw.id.au/> Folio <http://defoe.sourceforge.net/folio/> =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff JAVA2D-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
