POST
|
Hi, When building a project with the ArcGISRuntime, localization files are copied to build output. I was hoping for an option to add a property to my project file to only include language for only those languages I want, rather than all of them being copied to the output folder. Is that something that sounds reasonable to add to an upcoming version?
... View more
10-08-2020
04:39 AM
|
0
|
2
|
55
|
POST
|
Thanks for the reply. I can send the sample to Mike when I finish eating, if that is ok? I don't have your contact details, and the forum does't seem to allow me to attach files. And it is possibly easier to continue communication over email, in case we get further off topic of this thread
... View more
10-09-2019
11:56 AM
|
0
|
1
|
5
|
POST
|
It appears animated GIFs are turned into png, so the behavior is rather difficult to demonstrate with that format I have a 35" wide screen, and creating a map with Basemap.CreateLightGrayCanvas(), maximize the window, go to i.e scale 50.000, and zoom in and out between 1:25.000 and 1:50.000. in my sample, it takes between 2-4 seconds between start of SetViewpointCenterAsync and DrawStatus.Complete. On a standard 24" monitor, this duration is between 700 and 1500ms. Event handler for Esri.ArcGISRuntime.Http.ArcGISHttpClientHandler.HttpRequestBegin is not hit, so tiles are retrieved from cache.
... View more
10-09-2019
11:17 AM
|
0
|
0
|
20
|
POST
|
There are a few situations I've been looking into in regards to performance. Comparing .NET Core vs .NET Framework I've created two identical sample applications, except for one is .NET Framework 4.7.2, and the other is .NET Core. They both use HTTP/1.1 and the same initial extent. Manual testing: It feels like tiles take longer to complete drawing (DrawStatus.Complete) in the .NET Core application, compared to the one in .NET Framework, when zooming in and out in the same place. Automated testing: Both applications start working at the same time, and perform zoom in/out in tandem. Using this approach, the trend seems to be that the .NET Core usually takes longer, but I don't have definite proof, as they sometimes seem to change who takes the longest, based on stopwatch before performing SetViewpointScaleAsync, and DrawStatus.Complete. I don't know if the ServicePointManager.DefaultConnectionLimit Property (System.Net) | Microsoft Docs is affected across processes, and could have some sort of impact. Tiles from cache The real cause I noticed this, is the behavior in the attached animated GIF (hopefully it is displayed here). This is a rather large screen, which makes it more obvious. The tiles are loaded from cache, but the delay in drawing them is quite noticeable.
... View more
10-09-2019
11:01 AM
|
0
|
4
|
20
|
POST
|
Interesting. We are not quite ready to update to .NET Core yet, so we still have some time to work on it, and for MS to do the same. So in the future, the runtime will hopefully use the most suited protocol.
... View more
10-09-2019
10:33 AM
|
0
|
0
|
20
|
POST
|
Hi, I quickly whipped up a sample project for .NET Core 3.0 final to look for performance improvements, and in particular in regards to HTTP/2. However, looking at my IIS server logs, I can see requests made from Chrome are logged with HTTP/2.0, but from the sample application they are logged as 1.1. It appears that if I handle the ArcGISHttpClientHandler.HttpRequestBegin Event and assign e.Version = new Version(2,0), the requests is actually performed using HTTP/2. Shouldn't the Runtime use HTTP/2 by default without having to opt-in in this way, or is there something that I'm missing? Looking at a performance, I notice an odd artifact when zooming in and out on the same spot (one delta of the wheel), while there are no requests being made to the server, there is a visual appearance of the tiles being loaded from server rather than quickly/instantly retrieved from the cache, which I find odd. I already have an intermittent dialog with Michael Branscomb on the performance topic, so I was wondering if this should be part of the direct dialog, or in the forums.
... View more
10-08-2019
02:22 AM
|
0
|
8
|
20
|
POST
|
Thanks. I've already worked around the issue with my own locking, but I was hoping to reduce some additional locking and complexity in my own code. But I'm glad to hear the AddRange method is back
... View more
09-18-2019
01:19 AM
|
0
|
0
|
30
|
POST
|
Hi, I can see this issue has not been addressed for 100.6, so I was just wondering if it is on the shortlist for the next version?
... View more
09-17-2019
12:21 PM
|
0
|
2
|
30
|
POST
|
I've been able to make this work in 100.4. My short recipe is: - Load WebScene from portal - Iterate and LoadAsync on scene.BaseSurfaces.ElevationSources - await scene.BaseSurface.GetElevationAsync(point)
... View more
04-05-2019
12:02 AM
|
0
|
0
|
25
|
Online Status |
Offline
|
Date Last Visited |
11-11-2020
02:25 AM
|