Hello, udiggers!
Some words about rendering, seems especially for Jesse.
Simplifying of rendering that is what we need, indeed:)
I have some proposals.
For some reason, names of class are disappointing. I suggest to refactor a
bit, it saves our time to get understanding where is what.
What if to split RendererExecutor and Renderer interfaces and
implementation. Makes the architecture more clear, debugging also, etc.
So, the possible and sensible hierarchy of interfaces:
==============================
Renderer
-CompositeRenderer
RenderExecutor
===============================
The hierarchy of classes:
==============================
RendererImpl implements Renderer
-CompositeRendererImpl extends RendererImpl implements
CompositeRenderer
-RootRendererImpl extends RendererImpl implements
CompositeRenderer
RendererExecutorImpl implements RendererExecutor
- CompositeRendererExecutorImpl extends RendererExecutorImpl
- RootRendererExecutorImpl extends RendererExecutorImpl.
================================
Explanations:
What is the difference between Composite and Root executors and renderers.
Composite is an abstract entity following Composite design patterm. WMS
renderer can follow composite renderer API and can be executed by custom
implementation of CompositeRendererExecutor.. whatever like this.
Root executor and renderer are main classes responsible for the whole
process of rendering, management and updating SWT widget with image.
We have clear semantic. Only one root renderer, executor, context that are
very specific because of central management of rendering process and
updating SWT component.
RootRendererImpl contains simple or composite (like WMS) renderers,
executors, etc, actually has children.
Only RootExecutorImpl updates SWT component. whenever any rendering is going
on, root renderer must work in its thread to manage rendering process and
update viewport.
We start any usual renderer - through notifications RootRendererExecutor
must be started for updating.
The idea how to update SWT components. RootRendererExecutor manages its
children : renderers that are executed by their executors.
RootRendererExecutor contains queue that it reads , let's say, each second
(configurable value). All repainting commands from the queue are merged and
one redraw of SWT is performed with latest version of map image. All queue
events are read and deleted from queue forming just one request for
updating.
Imagine, 4 layers are ready (rendering is DONE) at 18.00.45.021 (where 021
is a milliseconds), 18.00.45.045, 18.00.45.067, 18.00.45.089 . 4 requests in
a queue and one actual updating of SWT at 18.00.46 (raw example)
Queue for repainting in RootRendererExecutor - what do you think about that
design?
RootRendererExecutor can also have configurable policy - whether anyway
update viewport each second or only when any requests are in queue - we have
freedom to play here.
Also, whenever any rendering is requested, first of all, all buffers must be
cleared (not in jobs, but earlier) otherwise stupid effect of overlapping of
different layers with different bounding boxes during zooming for example. I
mean files are rendered subsequently because of job rules but clearing is
performed in job.run(). Hope I am clear to explain this problem.
Also. What if RootRendererExecutor during merging of image from buffers
convert it into SWT image? Then we don't need to convert awt to swt each
time the viewport is repainted. It requires , of course, that DrawCommands
to be drawn using SWT graphics.. but gives a significant performance during
painting by tools at runtime, no gaps, no converting, just everything in
SWT. (For the future)
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..
Regards, Vitali.
_______________________________________________
User-friendly Desktop Internet GIS (uDig)
http://udig.refractions.net
http://lists.refractions.net/mailman/listinfo/udig-devel
