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
_______________________________________________
User-friendly Desktop Internet GIS (uDig)
http://udig.refractions.net
http://lists.refractions.net/mailman/listinfo/udig-devel
