Login | Register
My pages Projects Community openCollabNet

Discussions > dev > [gef-dev] Re: Quick question about synchronized paint in editor.java

Discussion topic

Back to topic list

[gef-dev] Re: Quick question about synchronized paint in editor.java


Author bobtarling
Full name Bob Tarling
Date 2010-12-14 02:31:19 PST
Message Hi Roland

I'm inlcuding the dev list for others to see this, best just reply
there from now on (are you subscribed?)

Yes, what you describe is my understanding too. I would expected there
*should* be no need to synchronise the paint but I can't guess at
someones reasons for putting this in place. GEF is truly an old
application and there is a great deal of history from before I joined
and the original developers are no longer active.

I'm not aware of any Graphics(or Graphics2D) implementation that would
require multithreading.

Once I can access I'll take a look at the subversion history to see if
I can see any clues as to why the sync was brought in. If its always
been there I'll drop Jason a line to see if he recalls any reason but
for him this is likely such an old project I guess he is unlikely to

If we can't find any logical reason then I'd be tempted to drop the
synchronize and release a beta for testing.



On 13 December 2010 22:43, Roland Quast <rquast at rolandquast dot com> wrote:
> Hi Bob,
> Sorry I wasn't clear at all on what I meant by the EDT. What I mean is that
> now days (I don't know the history of swing), but all paint methods should
> always be invoked by the Event Dispatcher Thread (a single thread). This
> means that paint doesn't have to be synchronized _unless_ there is another
> thread invoking either the paint methods or something like validate() or any
> of the non-thread safe methods. From what I understand, repaint(),
> revalidate() and a few others are all synchronized, so they can be called
> from any thread, but paint and validate should always be called from the
> event dispatcher thread and if they can't be called from the event
> dispatcher thread, you should call them from the EDT by placing the method
> calls on the EDT using SwingUtilities.invokeLater.
> Having said all that, I think part of the reason why it may be synchronized
> is not to do with the Java2D part of GEF, but something like a mock
> Graphics2D object that does painting (like an SVG writer or something). In
> that case, if the process that creates the SVG file (just an example) is
> multi-threaded, and it calls paint or validate, then it may require it.
> I noticed there was one place in the GEF code that validate() is called, by
> the component wasn't realized so I think it is okay.
> Now for the history bit - I am wondering if there wasn't an Event Dispatch
> Thread, or synchronized repaint(), revalidate() etc in the early history of
> swing (because GEF is so old) - and that the RedrawManager which used to be
> in the program was a type of Event Dispatch Thread. I don't know, but I just
> kind of had a hunch this may be what had been going on.
> Anyway, I just thought it was kind of weird that there was a synchronized
> paint method and it made me wonder if I was doing anything wrong by relying
> on the "all paint methods are running on the EDT" belief.
> Cheers,
> Roland.
> On 14/12/2010 12:25 AM, Bob Tarling wrote:
>> Synchronized paint doesn't sound too clever.
>> I'll take a look through the subversion history to see if I can find
>> any clues of why this got in and who commited it.
>> Could you clarify what you mean by EDT?
>> Regards
>> Bob
>> On 11 December 2010 01:21, Roland Quast<rquast@rola​ndquast.com> ¬†wrote:
>>> Hi Bob,
>>> Thanks for fixing the zoom issue! While I was looking at ways of making
>>> GEF
>>> rock solid, I noticed there were a lot of synchronized methods and blocks
>>> in
>>> GEF and thought I'd check out what they were synchronizing. From what I
>>> understand, most of them are to do with thread safety when
>>> accessing/modifying data from lists etc and key listeners. However, I
>>> noticed a peculiar one in Editor.java which appears to be a relic from
>>> the
>>> beginnings of GEF. The paint(Graphics g) method in Editor is
>>> synchronized.
>>>  From what I saw in the earlier code, it appears that GEF used to use a
>>> thing
>>> called RedrawManager to manage what I believe the EDT does now. Is there
>>> a
>>> reason why that method should be syncrhonized, and is there a reason for
>>> the
>>> shouldRepaint, and print(Graphics g) methods? Is this to do with backward
>>> compatibility?
>>> I know that it doesn't affect anything.. but because it is there, I was
>>> wondering if there is some special case that requires it to _not_ be run
>>> from the EDT?
>>> Cheers,
>>> Roland.

« Previous message in topic | 1 of 2 | Next message in topic »


Show all messages in topic

[gef-dev] Re: Quick question about synchronized paint in editor.java bobtarling Bob Tarling 2010-12-14 02:31:19 PST
     Re: [gef-dev] Quick question about synchronized paint in editor.java bobtarling Bob Tarling 2011-04-17 13:13:01 PDT
Messages per page: