[udig-devel] homework for udiggers Part 1

[Jesse Eichar]

On 29-Sep-06, at 4:59 AM, Vitali Diatchkov wrote:

>
> 1) Rendering.
>
> A lot of time was spent to learn, debug and understand rendering
> multi-threaded architecture. Significant improvements were changed  
> by bugs
> and back for the time being.
>
I am about to do a big simplifying process so Rendering is easier to  
debug and be less likely to have bugs.  Naturally i will ensure that  
there is a good set of test-cases when I am done so that bugs will no  
longer be fixed only to show up again.  I have some tests now but i  
have disabled then because they fail randomly.  I will use those  
tests as acceptance tests for the new implementations.

> Does the user really need progress of each layer rendering?  
> Especially when
> dozen of layers is on the map and rendering itself is time  
> consuming task.
> Updating status message, etc takes UI thread time.. There is a one  
> composite
> rendering thread that can be a "user" job and report whether  
> rendering is
> going on.
>
> The same situation with layer status decorations. I would like to  
> have an
> option to switch off rendering progress decoration.  stupid endless  
> blinking
> effects in Layers view. Lets make a rendering itself stable with good
> architecture, then decoration. Question of priorities and  
> concentrating on
> really important and critical things.

I completely agree with your points here.  I only a the  
CompositeRenderer now being shown as a non-System Job (IE has a  
progress) and am in the process of disabling the state  
notifications.  Thanks to the experimenting I have done the Rendering  
is a little buggy right now. But I am going to sit down and properly  
get all the units tests running and simplify the framework as much as  
possible so that it is stable and predictable.

>
>  Composite rendering thread that merges buffered images from usual  
> layers
> rendering threads - when the layer is rendered - updating is  
> performed, no
> updating during progress (again - the question of priorities - what  
> is more
> important: performance and clear logical behavior like "rendered- 
> >updated"
> or UI tricks like "let's the user see our cool rendering progress at
> run-time").

I still want that but I am simplifying it so that The composite  
renderer controls the entire process.  Before any renderer that  
indicated that it was done or running would trigger an update.  It  
was those that were causing too many refreshes.  A refresh per second  
should be acceptable from a performance POV.

> Some job is needed to refactor RendererCreator. Clean up the  
> handling of
> events when project model is changed: I mean I add layer - renderer  
> context
> must be created on the fly and the layer has to be rendered; I add  
> multiple
> layers - the same behavior but by one time - handling of multiple  
> events by
> one time. Such kind of improvements are desired.

This problem actually does not related to the RendererCreator.  It is  
because the drag and drop code breaks each drop down into many  
seperate actions and each action is executed seperately.  I have been  
working on fixing the problem for the last few days and now you can  
add as many layers as desired and it will only be a single drop action.

Jesse