[udig-devel] "Rendering" proposals
Jesse Eichar
jeichar at refractions.net
Tue Oct 3 09:50:49 PDT 2006
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..
More information about the udig-devel
mailing list