[Qgis-developer] Symbology NG - rendering of selected symbols

Thu Apr 8 19:36:13 EDT 2010

Thanks for the input Martin .. Worth waiting for as always.  Better that this sort of thing gets properly thought out than build a rushed implementation.  

I like the "hybrid" option for passing the selected status - ie passed as a parameter into the symbol but then stored and handled via the QgsSymbolV2RenderContext. 

Good point about symbols that don't have a fill.  Perhaps this can be handled when the cached symbols are created - if the selected and unselected version are identical then some sort of modification can be applied to the selected version...

Cheers
Chris 

-----Original Message-----
From: Martin Dobias [mailto:wonder.sk at gmail.com] 
Sent: Friday, 9 April 2010 8:40 a.m.
To: Chris Crook
Cc: qgis-developer at lists.osgeo.org
Subject: Re: [Qgis-developer] Symbology NG - rendering of selected symbols

Hi Chris

sorry for the lag, I'm too busy these days :-/

On Tue, Apr 6, 2010 at 12:13 AM, Chris Crook <ccrook at linz.govt.nz> wrote:
> I suppose I was thinking that the changes would need to be made in a minimal, non-breaking way, why I was thinking of adding renderSelectedFeature rather than adding a parameter to the renderFeature function, and by implementing this so it works continues to work with minimal changes for renderers which don't implement this function.  However maybe it isn't too late to make more dramatic changes - as this isn't the stable version!
>
> The other reason I can see for creating a separate function and implementation is that it ensures that if a new renderer doesn't provide an implementation for selected features, then they will still be visibly selected.

My idea is that the "V2" classes (which should replace the original ones in qgis 2.0) shouldn't be regarded as a part of the stable 1.x API. Such routines can be still a work in progress and not breaking anything could limit the development. Of course, there should be reasons for such breakage :)

> I think you are right in that it would be good for symbol layers to know how to render themselves when selected, and I guess just using setColor as a default implementation would work well, and give a better implementation than the current one.
>
> With the symbol layers potentially caching symbols in the start/stop functions I'm not sure how handling the selection flag at the symbol level would work.  I guess the ideal would be for the startRender function to be passed a flag to let the renderer/symbol/symbolLayer know that they may need a selected version.

Right, startRender() should take care of creating selected version of the symbol. I was thinking that in order to keep things simple, the symbol will always prepare itself to be able to draw also selected version - the runtime and memory overhead will be probably very small (one more cached image for markers) - but I have no strong opinion about this.

> I'm not sure I follow your thinking about using the QgsSymbolV2RenderContext to pass a selected flag, as it looks to me as if this is only created within the QgsSymbolV2 startRender, stopRender, and renderFeature funtions, where the selected status isn't available.

Sorry I wasn't clear. I thought about creating instances of QgsSymbolV2RenderContext already in the renderers and setting the selected flag there (and QgsSymbolV2 would just add the output unit and alpha). But that wouldn't be a nice approach either.

> I guess a boolean field in the QgsRenderContext could be used.  In the startRender function it would be used that the the renderer/symbol/symbolLayer needed to have a selected version available, and in the renderFeature function it would mean that the feature to be rendered is selected.

QgsRenderContext is currently immutable during the rendering of a
layer: all information is set before rendering, then there's only read access. It would be good to keep this semantics, that would be broken if a flag would be changed prior to each renderFeature call. And considering addition of parallelism (on the level of splitting a layer into chunks) in future, the QgsRenderContext would have to be cloned etc.

> Alternatively the selected flag could be added as a parameter to the startRender and renderFeature functions for the renderer, symbol, and symbol layer.

I like this approach currently at most. Only with the modification that the symbol layer could receive this flag in QgsSymbolV2RenderContext. Renderer and symbol would get an additional "selected" parameter (with false as an implicit value). Renderer's startRender doesn't need the flag because it gets pointer to the layer and can find out whether there are any selected features. Finally, symbol's startRender can receive the "layer has selected features"
flag and pass it to the symbol layer - but as I've written above, maybe this isn't necessary and all symbol layers could fall back to always prepare themselves for selected features.

> Certainly adding the flag to the context would be less work than changing function signatures through the symbology stack.  I'm not sure which would be the "more correct" implementation?
>
> So I guess I'm leaning towards:
>
> 1) Adding a boolean selected flag to QgsRenderContext, which is only used by the V2 renderers, used in startRender to indicate a selected symbology will be required, and renderFeature to indicate that the current feature is selected.

I think I've covered this above...

> 2) Updating QgsSimpleMarkerSymbolLayerV2 to optionally cache and use a 
> selected version of the image (using setColor to set the colour to the 
> selected colour ... Should this change the border colour too?)

I guess the border color should be kept, only the fill color should be changed... but then there are symbols like + or X that have no fill...

> 3) Update QgsFontMarkerSymbolLayerV2 to use the selected colour if it 
> is selected
> 4) Update QgsSvgMarkerSymbolLayerV2 to cache and use a selected version of the image. Not sure how to do this?  This should include an option for defining a selected version of the symbol (but maybe not yet implemented in GUI), and also some sort of default handling - perhaps creating a picture by rendering a larger background circle in the selected colour under the SVG image.

This is a bit tough. I'd avoid using a completely different svg symbol for selected version. When doing raster output (i.e. not to
pdf/printer/svg) then we could colorize the image by directly modifying the pixel colors. But I have no idea how to do that for pure vector output. So we should probably stick with a circle around the svg image as you suggest.

> 5) Update QgsSimpleLineSymbolLayerV2 and 
> QgsLineDecorationSymbolLayerV2 to create and optionally use a 
> mSelectedPen, and QgsMarkerLineSymbolLayerV2 to pass the selected flag 
> to its marker symbol
> 6) Update QgsMarkerLineSymbolLayerV2 to optionally use the selected colour, and QgsSVGFillSymbolLayer to optionally fill the polygon with the selected colour before applying the SVG fill.

Makes sense.

I hope the answers were worth the waiting :-)

Bye
Martin
______________________________________________________________________________________________________

This message contains information, which is confidential and may be subject to legal privilege. 
If you are not the intended recipient, you must not peruse, use, disseminate, distribute or copy this message.
If you have received this message in error, please notify us immediately (Phone 0800 665 463 or info at linz.govt.nz) and destroy the original message.
LINZ accepts no responsibility for changes to this email, or for any attachments, after its transmission from LINZ.

Thank you.
______________________________________________________________________________________________________