Re: updating an ImageIcon's backing BufferedImage content from multiple
threads
Peter Duniho wrote:
On Mon, 06 Apr 2009 08:29:21 -0700, Knute Johnson
<nospam@rabbitbrush.frazmtn.com> wrote:
[...]
So, the update to the BufferedImage must "happen before" the
redrawing of the component.
That's what I think too but I can't prove it.
Define "prove". :)
I don't have all of the nitty-gritty details that would prove it
incontrovertibly. But I don't see how EventQueue.invokeLater() could
work reliably if it didn't include exactly the kind of synchronization
that would guarantee this "happens before" relationship.
If things that occurred in code before the call to invokeLater() don't
"happen before" things that occur in code as a result of calling
invokeLater(), then invokeLater() isn't very useful, because you could
only access invariant or pre-synchronized data with it.
Pete
So do you think the same is true with repaint()?
Look what I just found,
From the article: Painting is AWT and Swing
http://java.sun.com/products/jfc/tsc/articles/painting/index.html#mgr
The RepaintManager
The purpose of Swing's RepaintManager class is to maximize the
efficiency of repaint processing on a Swing containment hierarchy, and
also to implement Swing's 'revalidation' mechanism (the latter will be a
subject for a separate article). It implements the repaint mechanism by
intercepting all repaint requests on Swing components (so they are no
longer processed by the AWT) and maintaining its own state on what needs
to be updated (known as "dirty regions"). Finally, it uses invokeLater()
to process the pending requests on the event dispatching thread, as
described in the section on "Repaint Processing" (option B).
I think I just answered my own question :-).
--
Knute Johnson
email s/nospam/knute2009/
--
Posted via NewsDemon.com - Premium Uncensored Newsgroup Service
------->>>>>>http://www.NewsDemon.com<<<<<<------
Unlimited Access, Anonymous Accounts, Uncensored Broadband Access