Safe to use Component.repaint() outside EDT?
Asked Answered
H

3

25

I cannot find any official documentation saying that it is safe to call Component.repaint from another thread than the Event Dispatch Thread, the EDT.

Is this so? And where can I find some documentation/code?

Halfblood answered 20/3, 2012 at 12:11 Comment(1)
good question +1, my helicopter views :-) --> a) everything works until repaint() isn't locked by Thread.sleep(int), b) there were a few topics about isEventDispatchThread(), but those lins are lost on plundered Java.Net c) agreed with API for AWT Components and for their nested classes in SwingPedigo
B
28

Here is a quote from an official page stating that:

The following JComponent methods are safe to call from any thread: repaint(), revalidate(), and invalidate(). The repaint() and revalidate() methods queue requests for the event-dispatching thread to call paint() and validate(), respectively.

EDIT 1 :


Since the previous link mentioned has been shifted. I am posting a new link, though it might take a bit more time to actually know the authenticity of this page, since it appears to be from Java though it originated from some University's server, as can be seen from the address bar.

Bibliolatry answered 20/3, 2012 at 12:18 Comment(2)
Both links don't work anymore, and I cannot find the referenced text anywhere :( Also note that the methods are not specified to be thread safe even if they are...Radiolucent
As the links are obsolete here is an updated link. "JComponent.repaint() registers an asynchronous repaint request to the component's RepaintManager, which uses invokeLater() to queue a Runnable to later process the request on the event dispatching thread."Spancel
S
8

It is thread-safe. The RepaintManager ensures that such calls are placed in the Event Dispatch Thread.

Painting in AWT and Swing ("official" documentation)

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).

For most programs, the RepaintManager can be viewed as part of Swing's internal system and can virtually be ignored. However, its API provides programs the option of gaining finer control over certain aspects of painting.

Stulin answered 20/3, 2012 at 12:13 Comment(2)
Thankx for this wonderful Painting Doc, I needed this stuff for so long :-), just couldn't find it. Seems like I was waiting for you to refer to it :-)Bibliolatry
@GagandeepBali: I rely on it, too. One handy way to find it is through the Component API.Salve
P
2

about the experiences on this forum

(+1 for both answerers) but, I think that not possible to answering your question correctly, part of methods Graphics(2D) required call for repaint() programatically, rest of them implementing this method (in API) directly (sure some of them missing this method in API)

for part of Swing JComponents is maybe better to dis-agree, this forum is full of questions about Concurency in Swing, starting with Graphics(2D) thought JTextComponents, JTree, and ends (same way is declared as thread safe) with setText(),

about Concurency in Swing are there notable numbers of questions

Pedigo answered 20/3, 2012 at 12:53 Comment(4)
ehhh ........ ? The answer to the question is clearly YES - no need to muddy the waters by possibly misbehaving unrelated codeGroundsheet
I'll endorse mKorbel's healthy skepticism: 1) APIs can change, although probably not repaint(). 2) While repaint() itself is thread-safe, one typically calls it after updating a component, which isn't thread-safe.Salve
@trahgod thanks for the translation :-) Though I tend to disagree a bit: a) there was no change, but a fix of a doc error (arguably the same thingy, it was a long story) b) if so, the code before calling repaint is wrong, not the repaint itselfGroundsheet
"about the experience on this forum" is something for Meta Stack Overflow, not for answers.Radiolucent

© 2022 - 2024 — McMap. All rights reserved.