MapGraphicsView->IdentifyGraphicsOverlay never finishing

BrianCrist · ‎07-16-2021

I'm experiencing a situation where identifyGraphicsOverlay calls are never indicating they've finished to the application. I've got an application with several layers of GraphicsOverlays, and when an end-user clicks on the mapView, I need to identify what items in which layer may have been clicked.

What I'm observing is that if I get "click happy" the identifyGraphicsOverlay calls will stack (I am keeping a list of taskWatchers) and nothing happens... eventually the mapView will lock up until I move the mouse off the application; at which point all of the tasks seem to execute and the mapView "frees up" as if nothing ever happened.

I've put in a monitor function to gain information about the taskWatchers, and they are valid and remain so. Here's a little bit of that monitor's output:

Other task count: 22 -- tasks started: 60 ; tasks finished: 38
"Hung states = [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid]"
Other task count: 22 -- tasks started: 60 ; tasks finished: 38
"Hung states = [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid]"
Other task count: 22 -- tasks started: 60 ; tasks finished: 38
"Hung states = [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid]"
Other task count: 22 -- tasks started: 60 ; tasks finished: 38
"Hung states = [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid]"
Other task count: 22 -- tasks started: 60 ; tasks finished: 38
"Hung states = [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid]"
Other task count: 22 -- tasks started: 60 ; tasks finished: 38
"Hung states = [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid]"
Other task count: 22 -- tasks started: 60 ; tasks finished: 38
"Hung states = [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid]"
Other task count: 22 -- tasks started: 60 ; tasks finished: 38
"Hung states = [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid]"
Other task count: 22 -- tasks started: 60 ; tasks finished: 38
"Hung states = [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid]"
Other task count: 22 -- tasks started: 60 ; tasks finished: 38
"Hung states = [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid]"
Other task count: 22 -- tasks started: 60 ; tasks finished: 38
"Hung states = [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid]"
Other task count: 22 -- tasks started: 60 ; tasks finished: 38
"Hung states = [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid] [valid]"

Again, as soon as I move the mouse off of the application, I am seeing this:

Other task count: 0 -- tasks started: 60 ; tasks finished: 60
Other task count: 0 -- tasks started: 60 ; tasks finished: 60
Other task count: 0 -- tasks started: 60 ; tasks finished: 60

Here is the relevant code:

connect(m_mapView,
        &MapGraphicsView::identifyGraphicsOverlayCompleted,
        this,
        &App::identify_overlay_completed);

...

void App::build_taskwatchers(const QList<our_layer_enum> layers_to_watch, const int x, const int y)
{
  constexpr double tolerance = 5;
  constexpr bool returnPopupsOnly = false;
  constexpr int maximumResults = 10;

  // Set up a bunch of identifyGraphics threads to see which (if any) overlay items
  // were clicked.
  for (our_layer_enum layer : layers_to_watch)
  {
    Esri::ArcGISRuntime::TaskWatcher tw =
            m_mapView->identifyGraphicsOverlay(m_overlays[layer].data(),
                                               x,
                                               y,
                                               tolerance,
                                               returnPopupsOnly,
                                               maximumResults);
  }
}

...

void App::identify_overlay_completed(const QUuid id,
                     Esri::ArcGISRuntime::IdentifyGraphicsOverlayResult * raw_result)
{
  ... do stuff

Again, if you click like a sane human, this all works fine. But our users tend to get click happy; and when they do so "identify_overlay_completed" is never called.

I have tried to do the

 identifyGraphicsOverlays / identifyGraphicsOverlaysCompleted

pairing instead, and it did the same thing; that is, it never finished tasks if someone was click happy.

I guess what I'm looking for is a way to actually have TaskWatcher::cancel work. I have tried cancelling the tasks in my little monitor function if they are aged out, and it does absolutely nothing.

The only (seemingly magical) way to get these stuck identifications unstuck is to move the mouse off of the application.

Note: I did build the "IdentifyGraphics" tutorial, and while it never freezes up, if you get click-happy with it, it will intermittently not pop up the "Tapped on Graphic" message. It never seems to lock up though.

JamesBallard1 · ‎07-20-2021

Hi @BrianCrist, can you provide some more details? What OS are you on and which version of the Runtime are you using? Do you have a lot of graphics in your overlay?

I am able to reproduce something similar by doing the following:

Run a template app in 3D (the one we provide with the SDK).
Add an ArcGISSceneLayer
Once the scene loads, start running identifyLayer operations in a loop covering the screen (around a thousand).
The tasks pile up and never complete like you're reporting.

Now with that being said, I am testing on macOS and using 100.11.2. Under typical conditions I was not able to reproduce the problem. I even implemented identify-on-mouse-move in the identify graphic sample you referenced which should overwhelm the API with identify calls as the mouse is moved around the screen. But even in that case all the tasks completed.

Furthermore, even with the problematic scenario I am running, it does not happen with our next release in development (coming soon!).

Here is some of the test code I used:

  connect(m_scene, &Scene::doneLoading, this, [this](Error)
  {
    QTimer::singleShot(2000, this, [this]()
    {
      // immediately run around ~1K identify operations to overwhelm the API
      const auto width = m_sceneView->widthInPixels();
      const auto height = m_sceneView->heightInPixels();
      for (int w = 0; w < width; w+=22)
      {
        for (int h = 0; h < height; h+=22)
        {
          constexpr double tolerance = 15.0;
          constexpr bool returnPopupsOnly = false;
          constexpr int maximumResults = 50;

          const auto watcher = m_sceneView->identifyLayer(m_sceneLayer, w, h, tolerance, returnPopupsOnly, maximumResults);
          const auto id = watcher.taskId();
          m_taskWatchers[id] = watcher;
          qDebug() << "Task started" << id << "total in progress" << m_taskWatchers.count();
        }
      }
    });
  });
// 
  connect(m_sceneView, &SceneQuickView::identifyLayerCompleted, this, [this](QUuid id, IdentifyLayerResult* result)
  {
    std::unique_ptr<IdentifyLayerResult> r(result);
    m_taskWatchers.remove(id);
    qDebug() << "Task done" << id << "total in progress" << m_taskWatchers.count();
  });

BrianCrist · ‎07-21-2021

Hi James, thanks for your response!

I am witnessing this in ArcGIS Runtime for QT version 100.10 running against QT 5.15.0 on an Ubuntu system (19.10). My primary computer is a Lenovo P1 Gen2 with 12 cores and 16gb of RAM. I've also observed this on a Dell 7220 tablet PC running Ubuntu 18.04 (I don't really know the hardware specs).

The "Mapping Environment" has a total of 8 overlays, and I would say the total number of graphics divided amongst those would number at most a few hundred (but I am observing the behavior with less than 100 graphic objects). Also I should note that at least a few of the graphics are updated (position/orientation) at up to a 20 Hz refresh rate. By "a few" I mean less than 10 generally speaking. It would be exceedingly rare that we are tracking more than 10 "active" graphics.

Also the situation seems to be exacerbated when there is an ENC (s.57) layer loaded underneath the graphics. I don't have any hard-and-fast data on this, but I definitely notice more trouble when an ENC is loaded than when there isn't an ENC.

I'm traveling today, but I will take a look at the code snippet you posted and see what I can see. One thing I should note is that I'm using a Map / MapGraphicsView (not a MapQuickView) and the application we have requires a 2-d presentation.

I can do a more thorough code posting if you'd like. (Again my internet access will be spotty today (7/21/21) but I can be online later this week).

Thanks again for looking into this,

Regards,

Brian

JamesBallard1 · ‎07-21-2021

@BrianCrist thanks for the additional info. I do think that what I was seeing was the same issue you are seeing and it doesn't happen with the version we have in development right now (100.12).

Another thing to note is that the 100.10 Runtime release is built with Qt 5.15.1, so you may run into subtle issues running against 5.15.0. I don't think that's related to the issue at hand, but I recommend jumping up to Qt 5.15.1 minimum or latest 5.15.X you have access to.