There do not need to be multiple RenderExecutors for selection

>Continuing to propagate "substitution" behavior of selection tools.
>Selection on another layer kills selection on the previous. Why each layer
>has the peer layer - SelectionLayer? If there are 10 layers - means there
>are 20 rendering jobs and at least 9 of them renders nothing. \
>
>
>What if there is one special SelectionLayer and one SelectionRenderer for it
>where all selection graphics is rendered.. Selection tools just send
>commands somehow to render something custom on this layer..
>
>This approach can be extended for adding any special graphics layers using
>special extension point for example - not only for rendering selection masks
>and graphics for selection tools.
>
>Rendering can be organized in a same way as ViewportPainter draws graphics
>above all maps - using commands.
>SelectionLayer has a special Renderer that has the same architecture as
>ViewportPainter
>
>All selection tools send two kinds of commands to that renderer: 1) just to
>start redrawing; 2) special drawing commands that have long life-cycle in a
>same way as in ViewportPainter. The second type of commands has a
>"substitution" behavior: each next command substitutes the old one.
>This idea outlines what do I mean - "substitutional" behavior in similar
>group of tools from other developers: such framework lets add new tools with
>new functionality but visual behavior among all tools from this "semantic"
>group in application remains the same.
>
The current frame work is not really viable right now when it come selection. But this solution won't quite work either but you make some excellent points. Right now a selection is only possible on feature layers. The rest of the framework does not make this assumption. I agree that only a single render executor is required for selection, since only one layer's selection is shown at a time. BUT there does need to be separate renderers for each layer. An example is there are likely to be Raster selection and editing tools so we would need a renderer that can render raster selections. It is possible that we need a new interface for selection renderers and have a method of selecting a selection renderer depending on the current configuration of uDig. Similar to what is done to choose the renderers used.