[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
[udig-devel] Re: Re: postRendering problem (bug??)
|
Absolutely. I'm probably one of the people with most interest in the
rendering given the dynamic nature of the application I'm putting together.
I'd be glad to help wherever I can: code, test, etc. One thing I think is
important is the use of Javadoc around published API's. I think, given the
nature of uDig as a development platform, it's critical that docs are in
when code is checked in. Checkstyle plugin maybe? :-)
"Jesse Eichar" <jeichar@xxxxxxxxxxxxxxx> wrote in
message news:4412103E-BF0E-480A-AFC3-7B954337C65F@xxxxxxxxxxxxxxx...
> Sounds great.... But you can expect me to tag you for help with testing
> ;-).
>
> BTW. I think I've fixed the bug that you reported with the Delete class
> and I made a second fix to the Fetcher class as well. Thanks for those
> stack traces... Very useful.
>
> Jesse
>
> On 29-Oct-06, at 5:10 PM, Andy Czerwonka wrote:
>
>> Ok. I'll do the simplest thing now to get it going and concentrate on
>> other
>> aspects of the system until the new rendering pieces are in.
>>
>> "Jesse Eichar" <jeichar@xxxxxxxxxxxxxxx> wrote in
>> message
>> news:AB2083A1-1C21-406B-BE96-6149317C9131@xxxxxxxxxxxxxxx...
>>> Don't get too attached to these classes. They will change after RC5.
>>> Once RC5 is out I am going to do some Rendering house cleaning. A
>>> great
>>> deal of simplification is going to take place.
>>>
>>> Jesse
>>>
>>>
>>> On 29-Oct-06, at 12:26 PM, Andy Czerwonka wrote:
>>>
>>>> I'm getting a message (it's intermittent) in the status bar saying:
>>>>
>>>> "Timed out while rendering this layer. Seems to have blocked, check
>>>> that
>>>> the
>>>> server is up"
>>>>
>>>> I don't think it's a valid message, given my layer is rendering just
>>>> fine.
>>>> I'm calling refresh from another thread (it's doing it safely) and
>>>> the
>>>> layer
>>>> is getting refreshed. I tracked down the message, and it seems that
>>>> the
>>>> implementation of
>>>> RenderExecutorComposite#CompositeRenderJob#postRendering()
>>>> is a little strange. If the IRenderer is not in the DONE state, then
>>>> we
>>>> get
>>>> the timeout message. Moving up the stack, I can't see how the
>>>> IRenderer
>>>> lifecycle is appropriately managed.
>>>>
>>>> Given this code: (RenderJob#run(IProgressMonitor))
>>>>
>>>> getExecutor().getRenderer().setState(IRenderer.RENDERING);
>>>>
>>>> try {
>>>>
>>>> startRendering(bounds, monitor);
>>>>
>>>> } catch (Throwable renderError) {
>>>>
>>>>
>>>> handleException(renderError);
>>>>
>>>> getExecutor().getRenderer().setState(IRenderer.DONE);
>>>>
>>>> return Status.OK_STATUS;
>>>>
>>>> }
>>>>
>>>>
>>>> postRendering();
>>>>
>>>> return Status.OK_STATUS;
>>>>
>>>>
>>>> The IRenderer may not get set to IRenderer.DONE.
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> User-friendly Desktop Internet GIS (uDig)
>>>> http://udig.refractions.net
>>>> http://lists.refractions.net/mailman/listinfo/udig-devel
>>>
>>
>>
>>
>> _______________________________________________
>> User-friendly Desktop Internet GIS (uDig)
>> http://udig.refractions.net
>> http://lists.refractions.net/mailman/listinfo/udig-devel
>