Skip to main content

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





Back to the top