This repository has been archived by the owner on Aug 8, 2023. It is now read-only.
Tile loading blocks map view updates but not user dot #1455
Labels
Milestone
Comments
1ec5
added
iOS
|
Currently, since we call |
|
Can you capture a set of stack traces when this occurs? |
|
Not sure what stack traces to provide, since the app doesn’t actually hang. (Should’ve said “stalled” or something above.) I can say for sure that |
|
Placing on beta 1 milestone because it’s so easy to get either a free-floating user dot or (with a hidden user dot) what looks like a hung app. Steps to reproduce:
(Edit: Step 1 is to set the simulated location in Xcode, but to be clear, this is running on the device, where tile loading is much, much slower than in the Simulator.) |
When it happens, hit the pause button in the debugger. I would expect to see the map thread blocked on something or doing heavy work -- the question is what. |
Two Worker threads appear to be busy: |
|
What likely happens is the following: When the user pans the map, we update the Transform (main thread), and trigger an update. Eventually the update will be executed (map thread). This triggers a |
|
At this point, I would consider the regression to be that the map stops redrawing while reparsing tiles. (If we also stopped the user dot from moving, it would still be perceived as a hang, and hangs are that much more jarring during gesture recognition.) In the past, was it the case that the Map thread remained unblocked while the Worker threads continued parsing? |
|
The stack traces show the map thread blocked waiting for worker tasks to complete during The workers are busy clipping and tessellating The situation is possibly exacerbated by the issue described in #1461. |
|
There's a check just up the stack, in the feature loop. Could clipping and tessellating a single feature really take long enough to cause a noticeable pause? |
|
I wouldn’t read too much into the top of the stacks, which vary widely. The only thing in common to each stack I’ve captured is that (re)parsing is occurring: |
|
I’m unable to reproduce any of this while profiling the demo app in Instruments using the Time Profiler instrument: performance in this configuration is just as good as in the Simulator. |
This check is effective, and processing a single feature typically only takes a few microseconds. The problem is a combination of two issues: When submitting WorkRequests, they are put into a queue until they are being processed. If the queue clogs up, the WorkRequests that are in the queue cannot be canceled, so joining the WorkRequest does a blocking wait until all previous WorkRequests in the queue have been processed, only to discover that the tile's state was marked as 4ccf246 intensified this problem by changing our worker pool from a shared queue to an individual queue for every thread with round-robin distribution of WorkRequests. This means there can be situations where a thread's work queue gets clogged up with work items while other workers would be available to process them. (#1471) |
This was referenced May 8, 2015
|
Should be significantly alleviated #1470 and the remaining performance optimization regarding distribution is ticketed; closing here. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Sometime in the last day or two (maybe due to #1326?), I’ve started noticing that
MGLMapViewoften hangs while parsing tiles (as opposed to waiting for them to come over the network). All the while, the user dot happily moves around in response to gestures, so it appears to glide around the map. Eventually the map catches up, but the result is very disorienting.Hopefully the hanging is captured elsewhere, but we should also attempt to keep the user dot from moving if the map is unable to rerender.
/cc @incanus @jfirebaugh @kkaefer
The text was updated successfully, but these errors were encountered: