Hello,
All below is applicable for ArcGIS Maps SDK for Qt 200.2.0.3963, but with earlier versions the behavior is the same.
We are using overlays in GraphicsRenderingMode::Dynamic, but also tried to change to GraphicsRenderingMode::Static, which differs just a bit.
Another thing is that we add a new shape in a newly created overlay and remove a previous overlay of the same shape. I've found this thread https://community.esri.com/t5/qt-maps-sdk-questions/graphicoverlay-on-mapview-blinking-how-to-fix/m-... about the very similar problem. The issue with this is that putting a shape in an existing overlay, leads to the situation that the existing overlay still contains rendering results of a previous shape, which leads to keeping an obsolete data in the picture. Removing of a previous shape from the overlay doesn't change anything.
Could you give some advices or/and propose approaches how to avoid/reduce the flickering?
Solved! Go to Solution.
Hey @anmy ,
Given your current implementation, with the amount of graphics being drawn it might be hard to avoid a flicker. Maybe `ClassBreaksRenderer` would be a good candidate for you? Here is a sample showing it's use, https://github.com/Esri/arcgis-maps-sdk-samples-qt/tree/main/CppSamples/Layers/ChangeSublayerRendere....
I am unsure of how you are getting the temperature and audio intensity data but I think setting the overlays renderer to ClassBreaksRenderer with ClassBreaks defined at the specified ranges you want could work in your case and I would expect better performance as well.
What do you think?
Could you add some details about what your workflow is? Is it simply adding graphics on top of each other with the same symbology? A code snippet that illustrates the issue so we can reproduce it would be great.
Thanks,
Lucas
Thanks for your replay, Lucas.
It's adding of simple (might be overlapped by borders) graphics, but with quite a lot of differently colored symbols, which are changing, as the coloring is changing over time.
I am adding a minimal reproducible code here. It's based on the example arcgis-maps-sdk-samples-qt/CppSamples/DisplayInformation/GODictionaryRenderer at main · Esri/arcgis-..., but doesn't use any offline data and the DictionaryRenderer itself, just as the base.
As you can see in the video, it doesn't blink on every update, but still we have complains from our customers, as sometimes it happens quite often and too hard for eyes.
We are glad to hear about any alternative approaches.
Best regards,
Anton
Hey @anmy ,
Might I ask for you to expand on your workflow/use case? I can observe the `flicker` when reproducing it locally but it doesn't rise to the level of causing irritation of the eyes.
Sincerely,
Jared
Hey @JaredCaccamo,
Our main use case is visualization of temperature or audio intensity measured by a fiber as a sensor. Resolution can be between 25 cm and several meters depending on a fiber length, which in complex systems can reach several hundred kilometers. In case of audio intensity, content may change several times per second, in case of temperature once per several minutes. So, the audio intensity case is currently more crucial for us.
As you can see in the topic-start post's videos captured from our application, the flickering can be more irritated than in the artificial example.
We would appreciate any suggestion with an approach alternative to creation of a huge amount of small polygons.
Best regards,
Anton
Hey @anmy ,
Given your current implementation, with the amount of graphics being drawn it might be hard to avoid a flicker. Maybe `ClassBreaksRenderer` would be a good candidate for you? Here is a sample showing it's use, https://github.com/Esri/arcgis-maps-sdk-samples-qt/tree/main/CppSamples/Layers/ChangeSublayerRendere....
I am unsure of how you are getting the temperature and audio intensity data but I think setting the overlays renderer to ClassBreaksRenderer with ClassBreaks defined at the specified ranges you want could work in your case and I would expect better performance as well.
What do you think?
Thank you @JaredCaccamo and @LucasDanzinger ! We could finally apply the solution you proposed and it works much better and stable than the previous one we had.