[prev in list] [next in list] [prev in thread] [next in thread] 

List:       batik-dev
Subject:    DO NOT REPLY [Bug 40994]  - MemoryMonitor updates outside of Swing thread
From:       bugzilla () apache ! org
Date:       2006-12-24 16:08:46
Message-ID: 20061224160846.731FA714295 () brutus ! apache ! org
[Download RAW message or body]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=40994>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=40994





------- Additional Comments From deweese@apache.org  2006-12-24 08:08 -------
> (In reply to comment #5)
> > This is fixed in SVN.

(In reply to comment #6)
> isn't this directly related to the other question with
> updates-outside-of-swing-thread??
> i would say, calling component.repaint() is/was enough.
> what do i miss??

   Well the 'RepaintThread' doesn't just call 'repaint'
it actually calls 'memoryStateChanged' listeners on the
Swing components.  The 'History' part of the window in 
particular then modifies a number of internal data
structures that are also used during the Swing repaint.

   The two options were to make these methods thread
safe (which there is a reasonable argument for), or
to make the memoryStateChanged 'events' be delivered
only in the swing thread (so they can't cause problems
with the swing repaint).  I picked the latter as it
seemed easier...

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-dev-help@xmlgraphics.apache.org

[prev in list] [next in list] [prev in thread] [next in thread]