Latest Contributions by BjørnarSundsbø1

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

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

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

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

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

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