[
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
>