You have nicely summarized my plan. With a few points (the request
queue for example) that I will add to my plan. Essentially I am
going to have the "root" object much more in control of the behaviour
of the renderers, such as clearing the images, dictating when
rendering starts and stops, etc... There will be no
CompositeRenderer (the root object will take its responsibilites
along with the RenderExecutorComposite). There will be less
eventing. Rather renderers can make requests to the "root" object.
(What's a good name? we've already used RenderManager).
I will make some sequence and class diagrams and publish them on the
WIKI. Lets use that as a place for collaboration.
For the sequence diagrams I am using a simple program:
http://udig.refractions.net/confluence/download/attachments/9218/
sequence-10.0.jar
for creating and editing them. I will post the files as well as
images on to the page when I have some ready. you are welcom to do
the same.
Jesse
Summary:
1) Clear up class names, listeners names, API to follow design pattern
semantic and business process: how is responsible for what.
2) "Root" concept in rendering process management, queue, updating
job,
comminications in both directions: Root renderer can cause child
renderers
to be executed, each child renderer being requested has to invoke root
renderer to be started for updating.
3) Whenever bounds in renderer are changed - clear buffer for not
to confuse
users. The user needs to see what he requests, not intermediate
steps. Zoom
in - clear everything and no old data to be rendered from buffers
if it was
not yet cleared because of current implementation in jobs that are
delayed.
I am sure the rendering is one of the corner stones. My goal is to
share
experience and proposals, then implement something if the idea is
acknowledged. Whenever the best solution is found - implement it.
Correct me
if I don't get to understand something..
_______________________________________________
User-friendly Desktop Internet GIS (uDig)
http://udig.refractions.net
http://lists.refractions.net/mailman/listinfo/udig-devel
