|
POST
|
See my response here: https://community.esri.com/message/933576-re-how-do-i-get-a-reference-to-systemlocationdatasource-in-net-standard-librar…
... View more
07-31-2020
10:04 AM
|
0
|
4
|
4201
|
|
POST
|
That looks like a marker symbol texture ending up on the map somehow. That's definitely a new one. Any chance you can make a small reproducer ? I think we'd need to debug this issue to understand how this could happen.
... View more
07-28-2020
10:00 AM
|
0
|
0
|
1905
|
|
POST
|
The temporary .geodatabase files are used by the renderer engine to manage data from feature services and tile services. What specifically is internal and isn't really documented, but I don't see a way to avoid those being created - the alternative would be to put it in memory, and then you'd have a completely new set of problems. Again files _should_ be cleaned up once the data is no longer in use - if not that might be a problem that needs investigating. Note though that if you shut the app down forcefully (stopping a debug session in visual studio or killing the process for instance), that wouldn't get a chance to happen. You definitely shouldn't be roaming this data, so make sure you set the temp path to a non-roaming folder.
... View more
07-22-2020
11:53 AM
|
0
|
0
|
4336
|
|
POST
|
The files are supposed to get cleared out once the layer is out of scope and garbage collection (which also happens on shutdown). I can't say for sure why that's not happening here. Having said that, if you set the ArcGISRuntimeEnvironment.TempPath Property property, you can delete all the contents in this folder on shutdown to create a complete cleanup of everything and anything.
... View more
07-21-2020
12:19 PM
|
0
|
2
|
4336
|
|
POST
|
> But it seems that 64bit emulator could be supported too No that would be called x86_64. arm64-v8a is what your pixel device uses. Is also pretty clearly states 'Only x86-based Android Emulator architectures are supported'. The statement you're referring to are for deployments in the store, and refers to ARM devices, or x86_64 devices (which effectively means you would never be able to ship an ARCore based app on x86, and thus only arm64 would really be supported)
... View more
07-19-2020
10:59 AM
|
1
|
1
|
3438
|
|
POST
|
To be honest, we never even tried using the emulator (I think that is support that was recently added after we developed the AR control). So I can't say if there's a way to make it work, but googling this specific error, lots of people report this, unrelated to our AR toolkit. I can't imagine testing with the emulator would be a good experience though, as it's the movement of the device that gives you the best sense of how it's working. You can just plug your device into your PC, and Visual Studio should detect it and you can choose to deploy to it right from clicking the Run button, and it'll take care of building, deploying and launching the package, so you can debug your code. If you do get it working with the emulator, I'd love to hear about it, but again the error doesn't seem specific to our SDK, albeit it might be the version we rely on doesn't support x86 architecture.
... View more
07-19-2020
08:54 AM
|
1
|
3
|
3438
|
|
POST
|
When you say virtual device, do you mean an emulator? We have working on supporting this on real hardware.
... View more
07-19-2020
07:58 AM
|
0
|
5
|
3438
|
|
POST
|
Thank you! All this info is very helpful. The new videos definitely shows it clearer.
... View more
07-17-2020
11:24 AM
|
0
|
2
|
3671
|
|
POST
|
It's basically identical to the sample you linked to, but with sceneview and the ScreenToBaseSurface method instead of ScreenToLocation.
... View more
07-17-2020
11:10 AM
|
2
|
0
|
4078
|
|
POST
|
Thank you for all this testing and the details. This is helpful. I'm curious how you're testing the framerate? There were a few changes that could affect these metrics and not give you the right number (WPF can be a little weird in that respect). However I'm assuming that besides measuring, you are visually seeing a significant difference? Also are you seeing the same behavior with panning, and not just mouse-wheel zooming?
... View more
07-17-2020
10:00 AM
|
0
|
5
|
3671
|
|
POST
|
You can use the Scene.ScreenToBaseSurface method from a MouseMove event: https://developers.arcgis.com/net/latest/wpf/api-reference/html/M_Esri_ArcGISRuntime_UI_Controls_SceneView_ScreenToBaseSurface.htm There's also a more accurate ScreenToLocationAsync method that takes data in layers into account, but this is a lot slower and not recommended to be used on a mouse move event.
... View more
07-16-2020
11:32 PM
|
0
|
3
|
4078
|
|
POST
|
Thanks for that extra info. Just to help narrow things down, do you see the issue in 100.7 as well?
... View more
07-15-2020
02:11 PM
|
0
|
17
|
7073
|
|
POST
|
Aaaah that's the Pro SDK, and not the Runtime SDK. Let me see if I can't move this thread over there....
... View more
07-15-2020
09:28 AM
|
1
|
0
|
2437
|
|
POST
|
We don't have a ProgressDialog in the ArcGIS Runtime SDK. Is this a platform specific question? (A quick search seems to indicate this might be an Android control, so generally we recommend using android-specific forums,or stack overflow etc for generic platform questions)
... View more
07-15-2020
08:25 AM
|
0
|
0
|
2437
|
|
POST
|
Do you see the same problem with no extra data loaded? If not, at what point do you start seeing this degradation? > I'm wondering if having a bunch of TPKs loaded ahead of time is slowing it down, even though the TPKs are mostly not in the viewing are More layers definitely will have an effect on performance, but I would have expected that hit to be the same as with 100.6 and not getting worse.
... View more
07-15-2020
08:22 AM
|
0
|
20
|
7073
|
| Title | Kudos | Posted |
|---|---|---|
| 2 | 05-11-2026 07:05 AM | |
| 2 | 03-19-2026 06:03 PM | |
| 1 | 03-03-2026 04:41 PM | |
| 1 | 02-26-2018 07:53 AM | |
| 1 | 02-26-2018 07:51 AM |
| Online Status |
Offline
|
| Date Last Visited |
2 weeks ago
|