Release date of 'Update One'

1860
10
02-06-2017 06:18 AM
NorbertThoden
Occasional Contributor III

Hi!

Has anyone information about the release date of 'Update One'?

Maybe ebader-esristaff‌ has some info?

Thx

0 Kudos
10 Replies
EricBader
Occasional Contributor III

Hi Norbert,

Thanks for asking! The current plan is end of May 2017.

JonathonGrivas
New Contributor III

So there won't be any bugfixes or performance updates until (maybe) May? That's a long time to live with the issues that have existed since day one.  

For example:

  • When large quantities of features are present in the map, panning around and zooming cause the features to flicker on and off - it's not a breaking bug but it makes this platform very undesirable to use.
  •  Feature caching also doesn't work, causing massive data usage and tons of duplicate requests being sent out, not to mention the wasted processing time (my cpu floors a thread for 5 seconds literally every time I pan the map, even if it's just by 1 pixel - I can only imagine what damage this is doing to mobile battery life).
  • Tile loading is inexplicably slow. Using the same online tile cache with the javascript API yields no such problem.
  • There are numerous other issues already documented in the release notes, many of which have a great impact on our apps.  

I know some of the things I mentioned are only poor performance and not necessarily bugs, but performance is one of the primary benefits of Qt over web. Half a year between updates is pretty tough to swallow if there are this many issues with each release. Is there any way issues like these can be addressed in a reasonable time-span instead of being bundled with major releases?

NorbertThoden
Occasional Contributor III

Hi Jonathon!

I would like to support your post.

I spend a huge amount of time finding bugs and prepare them for the support team...

Unfortunately i don`t know anything about their state until now...

But i have to mention: Luke Danziger and Luke Smallwood are very helpful within this forum! - Thanks!

EricBader
Occasional Contributor III

Hi Jonathon,

Thank you for sharing these issues. I'm sorry to hear of your struggles with these pain points. We hear you. We continue to work hard on improving performance, this is a huge priority for everyone, I agree.

Have you had a chance to log the feature caching and tile loading issues (bullets 2 and 3) with Esri Support, with the details? We were aware of the flickering in 10.2.x, haven't gotten feedback about this showing up in 100.0. You're developing with 100.0?

Norbert, I agree..."the Lukes" are great.

Thanks!

Eric

0 Kudos
JonathonGrivas
New Contributor III

I did report the feature cache issue, I receieved an email from someone saying they'd look into it, but never heard any more. 

Yes I am using version 100.0, flickering may have been the wrong word. Feature layers appear to turn on and off in sequence after panning/zooming. The frustrating part is that the features are there (and properly translated/scaled) right after panning/zooming, but then disappear and reappear a short time later. It seems to be going through them 1 layer at a time. This also significantly slows down interaction with the feature layers as they don't seem to respond until after they disappear and reappear.   Additionally, even just turning on the layers takes a strange amount of time. I have a layer with somewhere around 1500 features in it. When I add that layer with the JS api, it takes about 1 second to load and never brings my chrome thread above 5% cpu, when I do it in QT it takes 5 seconds and the thread goes up to 16% cpu the whole time.  I remember having a similar problem in 10.2.6, I can't believe it's still going on. I remember CPU utilization skyrocketing every time a json feature response came back from the server. Miraculously this performs far better on my android tablet than it does on my desktop, but it's still very bad. My desktop is orders of magnitude faster than the tablet so I'm not sure what's causing that performance disparity.

The tile loading is less of an issue - it works, it's just slower than the JS api's tiles. On the release notes there is something written about tiles performing slowly when features are on the map, I assume that's what it is. 

0 Kudos
JonathonGrivas
New Contributor III

Do you have any information about the feature layer performance issue?  I'm running the exact same map service side by side using the JS api and the QT SDK and the js api is buttery smooth while the QT SDK floors the CPU and takes full seconds (plural) to render the layers every time you pan/zoom.  Surely you guys have rendered maps with multiple feature layers and thousands of features before, do you experience this problem? Are there workarounds or any plans to fix it soon? This has become a major issue, we switched to QT from JS to improve mobile performance and now we're experiencing the opposite effect.  

0 Kudos
EricBader
Occasional Contributor III

Hi Jonathon,

I apologize for the delayed response.

We are aware of this issue. We're you able to get a response from Support on this?

It's very odd that your Android tablet gives your a better experience than your desktop. What's the OS?

0 Kudos
JonathonGrivas
New Contributor III

Thanks for getting back to me. The tablet is a Samsung and running Android 6.02.  The app performs better in almost every respect on the tablet than on my desktop (although the flickering and redrawing of feature layers is still extremely bad). Perhaps I have a problem on my desktop, but other cpu/network intensive applications run without a hitch. 

0 Kudos
EricBader
Occasional Contributor III

Thanks!

What about your desktop OS? 

0 Kudos