Login | Register
My pages Projects Community openCollabNet

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

gef
Discussion topic

Back to topic list

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

Reply

Author bobtarling
Full name Bob Tarling
Date 2011-04-17 13:13:01 PDT
Message Sorry I sat on this so long Roland

I'll remove the synchnonize and release a beta.

Lets then just keep an eye on things and see how it goes.

Regards

Bob

On 14 December 2010 10:31, Bob Tarling <bobtarling at tigris dot org> wrote:
> 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
> remember.
>
> If we can't find any logical reason then I'd be tempted to drop the
> synchronize and release a beta for testing.
>
> Regards
>
> Bob
>
> 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 | 2 of 2 | Next message in topic »

Messages

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: