Bug removing CompositeSymbols from GraphicsOverlay

[KevinSayer]

Hi Guys,

We seem to have found an issue with the ArcGISRuntime SDK for .net 100.8 release that's a regression over 100.7

Our application uses CompositeSymbols to represent our chart items, each containing 3 symbols: 1 PictureMarkerSymbol, 1 TextSymbol and 1 SimpleMarkerSymbol.

These composite symbols are displayed on a GraphicsOverlay with the rendering mode set to Dynamic.

We have implemented our own clustering algorithm that potentially removes existing graphics from the GraphicsOverlay and replaces them with new graphics when zooming in and out.  The new graphics are displayed using various composite symbols to represent clusters in differing states of selection i.e Unselected, partially selected and fully selected.

The issue we are seeing is that when zooming in and out,  the graphics overlay still displays random constituent parts of composite symbols for graphics that have been deleted.

For efficiency reasons, we actually only remove the graphics that are not being consumed by a new cluster, however testing has shown that even if we delete ALL graphics from the overlay (either iteratively or using the Clear method) before adding back the graphics relevant to the new zoom level, we're still left with these random remnants.

This only seems to be a problem when the GraphicsOverlay's RenderingMode is set to Dynamic and it also seems to be triggered by the combination of a PictureSymbol AND a TextSymbol.  Just one graphic with this combination of symbols causes all other composite symbols (even cluster symbols that only contain SimpleMarkerSymbols and a TextSymbol) to randomly behave in the manner described.

It's worth noting that once a remnant is present, it never disappears (at any zoom level) and is not reported as being present in the GraphicOverlay's graphics collection.

For now we're working around this issue by using the Static rendering mode on the Graphics overlay, but that's obviously less visually appealing to our end users.  Could you therefore please look into this to confirm the issue and let us know when it is likely to be fixed?

Attached are a couple of images demonstrating the problem.

The first map represents 6 of our chart items, (2 individual items and 4 inside a partially selected cluster)

The second is the same map zoomed in one level where the cluster of 4 items has split into 2 clusters of 2 items.  Note the central blue and white circle with orange selection glow.  This is a remnant of the composite symbol for the 4 item cluster shown at the previous zoom level, minus the TextSymbol showing the count which has clearly been deleted as expected.  The graphic for this symbol has been deleted from the overlay and the overlays's graphic count is 4 despite there clearly being 5 composite symbols present.

Regards,
Kevin.

[Nicholas-Furness]

Hi.

Sorry you're having problems here. Looks like something we'll have to look into.

In the meantime, have you considered creating a new GraphicsOverlay when the zoom level changes? Seems like right now you're manipulating the existing graphics in a single GraphicsOverlay to come up with a new collection when the zoom level changes. If instead you come up with the new set of representative graphics and place them in a new GraphicsOverlay and remove the one being used for the previous zoom level, does this remove the stuck artifact? You should of course be able to use a single graphics overlay and not have to swap them out, but I wonder if this can help you in the meantime. And GraphicsOverlays are not very heavyweight so this workaround shouldn't impose a performance hit.

One other thought: have you tried explicitly deselecting the selected graphic before it's removed?

Cheers,

Nick.

P.S. This won't necessarily help, but just for reference here's a cluster layer I built for iOS. It uses a FeatureCollectionLayer instead of Graphics in a GraphicsOverlay, which means you can put your layer anywhere in the operational layer stack: clusterlayer-plugin-ios

[KevinSayer]

Hi Nicholas,

Thanks for your reply.  I did consider creating a new instance of the GraphicsOverlay after each zoom operation as that would presumably have a clean graphics collection with no dodgy artifacts from the previous overlay.  I don't think this would give us the same smooth effect however and will possibly introduce flicker of its own. We already don't remove graphics that are still relevant after clustering has been applied to avoid flicker, and this approach would negate that.  Unfortunately the GraphicsOverlay is also woven into our architecture to give context for our multi-chart environment and as such it's not a local object that's easy to switch out for a new instance.  A quick test is therefore not possible, but I think it's likely to introduce similar flicker to clearing the whole overlay and adding all the graphics back in, which we currently avoid.

We are on the cusp of a release right now where the mapping component is just one part of a much bigger product and we were actually waiting on your 100.8 release to fix a PKI problem that we've been collaborating on.

Clearly we were hoping to just reference the new assembly and move ahead but unfortunately this issue has arisen in testing.  I think we will probably have to ship with the rendering mode set to Static and wait for a future fix/update to resolve this new problem.

Just to address your other question, I can confirm that selection doesn't have anything to do with the repro.  It just happens to be the case that the screenshots I provided had a selected cluster that was removed but the same problem occurs even when nothing is selected.

We also use the Graphics overlay, rather than a feature layer as each symbol is potentially unique in terms of it's graphic and text so this seemed like the appropriate solution.  i.e It's not static symbology which I believe a Feature Layer is more aligned with.  That may be an incorrect assumption so please feel to correct me if you still think a Feature Layer would be a better option we should consider for the future...

Regards,
Kevin

[PreetiMaske]

Hi,

I have been trying to replicate the problem in a simple reproducer but have not been successful so far. To mimic your workflow I added three graphics o the graphics overlay. When map is zoomed to a scale less than 100 I remove one graphic otherwise add it back.

To help us troubleshoot the problem, would it possible for you to recreate the problem in a simpler app? I am also sharing my test app if you want to build on top of it. 

Thanks,

Preeti

[KevinSayer]

Hi Preeti,

Thanks for looking into this for us.  Your application only uses a SimpleMarkerSymbol and a TextSymbol in the composite symbol but as I said above, the bug only seems to occur with the combination of a PictureSymbol and a TextSymbol, so you will need to add a PictureSymbol too.

Regards,

Kevin

[PreetiMaske]

Kevin,

Even after adding PictureMarkerSymbol I am unable to reproduce the problem. Attached the app I had with picture marker symbol.  So far I have tried all three combinations below and none of them result in the behavior reported.

- Simple Marker + Text

- Text + Picture marker

- Simple marker + text + picture

It would be hard to proceed with any diagnosis until we get to reproduce the issue. Question: how is the text for the text symbol calculated? is there any use of visual variables or arcade expressions on other layers on the map?  Is it possible for you to provide a reproducer ? You can start of with the basic app attached . I can help if needed but we need a reproducer to move forward.

Regard,

-- Preeti

[PreetiMaske]

Kevin,

Just wanted to share that I have been able to reproduce the problem and have logged a bug in our internal bug tracking system. 

Thanks for reporting the issue.

Cheers,

Preeti

[KevinSayer]

Hi Preeti,

Glad to hear you managed to reproduce this and thanks for the update.  Hopefully this will be fixed in the next release and we can revert to using the Dynamic rendering mode.

Regards,

Kevin