Latest Contributions by JamesBallard1

‎10-27-2021

Hi @FatmaAkdemir , If it works fine when the files are local, but is laggy when accessing the files over a network samba share, it sounds like a network latency issue. If both computers are Linux, NFS might be better performance but that's a guess. You could implement some caching algorithms to store the images locally in /tmp as they're accessed, and retrieve them from local disk if they are accessed again. The first access would still be slow. Another idea would be to index and store all your tile images into a database. Then in your method that gets the tile bytes, it would be a sql (or whatever db) call rather than accessing files over the network. That may not work depending on how many tiles you have. https://doc.qt.io/qt-5/sql-driver.html Another thought would be to compress your tiles and store them at lower resolutions (so smaller file sizes) so they can be read quicker over the samba mount. Lots of options, but the core issue sounds like the network latency and not the Runtime. You can likely measure the data read times and compare to local file access to see how much network latency you're dealing with to decide on the best course of action. I hope this help.

‎10-26-2021

Hi @DrewMorris . Would you mind posting this over in the AppStudio community? They are better suited to to answer specific questions about the AppStudio frameworks and deprecations. https://community.esri.com/t5/arcgis-appstudio-questions/bd-p/arcgis-appstudio-questions

‎10-19-2021

Hi @GarethBlock_Ti , We've seen this with other folks reporting similar issues. It seems to happen when you use Qt provided by the package manager or other similar means. These are built with version tagging enabled. We build our SDK against the version of Qt provided by the Qt Company directly. The first thing to try would be downloading Qt from the Qt Company directly and see if that fixes it: https://www.qt.io/download . If that's not possible, the next thing would be to see if you can obtain the Qt sources and build the version you want using the Qt Company's method. The key would be to disable the version tagging via QT_NO_VERSION_TAGGING during the configure step. The other one we've seen is " operator delete(void*, unsigned long)@Qt_5". Let us know if this helps.

‎10-12-2021

@MarkCederholm we checked into it and sure enough we do have a bug in Qt. We are fixing it for the upcoming 100.13 release, but in the meantime here's a workaround to get the time down for Qt. // Generate multipoint geometry MultipointBuilder* mb = new MultipointBuilder(_sr, NULL); auto points = mb->points(); for (int i = 0; i < iNumPoints; i++) { double dX = dXMin + (dXMax - dXMin) * _rand->generateDouble(); double dY = dYMin + (dYMax - dYMin) * _rand->generateDouble(); points->addPoint(dX, dY); } We weren't caching the PointCollection class internally, and calling mb->points() in a loop that way exposed the issue. In my testing the code with that one change drops from around ~32 seconds (on macOS) to ~4 seconds. I'd be interested to hear if you see a similar speedup with that change, but not required. Thank you again for posting this. You helped us identify and fix a bug!

‎09-30-2021

@MarkCederholm , thanks for posting this. I agree with everything @dotMorten_esri said. We will look into this on the Qt team to make sure we do not have this type of overhead compared to .NET and Java Runtime SDKs. The numbers are very surprising that the Qt C++ SDK, which is native C++ through the entire stack, would be roughly twice as slow as our companion Runtime SDKs.

‎09-24-2021

@JustinSteventon sorry for the delay. I will log an internal issue for the team to keep looking into this. In the meantime I encourage you to open an official support request.

‎09-15-2021

@JustinSteventon, thanks for the extra info. I still cannot reproduce the problem on my end. One of my colleagues attempted and also couldn't reproduce it. The stack trace is limited, so hard to tell from that. Are you able to determine which call is the culprit that's crashing? I can see in the stack it's getting into our Runtime library, but that's all. Hopefully it's not a Heisenbug that suddenly works fine after you alter the code with some logging. For example, does this code point to a particular function that's crashing? onViewpointChanged: { console.log("screenToLocation"); let screenToLocation = mapView.screenToLocation(width / 2, height / 2); console.log("Factory.SpatialReference.createWgs84()"); let sr = Factory.SpatialReference.createWgs84(); console.log("GeometryEngine.project"); let point = GeometryEngine.project(screenToLocation, sr); console.log("ArcGISRuntimeEnvironment.createObject"); let viewpoint = ArcGISRuntimeEnvironment.createObject("ViewpointCenter", {center: point, targetScale: mapView.mapScale}) console.log(JSON.stringify(viewpoint.json)) }

‎09-14-2021

Hi @JustinSteventon , Thanks for providing the test project. That is very helpful in assisting us with reproducing the problem. Unfortunately, I cannot reproduce the problem on macOS with Qt 5.15.2 or 5.15.5, or with Qt 5.15.5 on iOS. All my tests were with 100.12. The only tweak I made to the code was this, aside from an API key to get the basemap working. console.log(JSON.stringify(viewpoint.json)) But even without that change it did not crash. Can you provide some more information? What version of Qt are you using? Can you provide a stack trace of the crash on macOS? Also, can you confirm if your version of the app has an API key and the basemap is rendering?

‎09-03-2021

That's great to hear, @Jean-Philippe . We're always happy to help, so don't hesitate to reach out with any other questions.

‎09-02-2021

@Jean-Philippe , It sounds like you're on the right track. It's suspicious that numberOfFeatures would return 0 if that feature table is rendering data. ShapefileFeatureTable is a Loadable object, so before running any async tasks with it or checking the number of features, you must make sure it's loaded first. Please confirm if the table is loaded and then we can troubleshoot further. Here's an example. ShapefileFeatureTable* table = new ShapefileFeatureTable("/path/to/myData.shp", this); connect(table, &ShapefileFeatureTable::doneLoading, this, [table](Error e) { if (!e.isEmpty()) { qDebug() << "table failed to load:" << e.message() << e.additionalMessage(); return; } qDebug() << table->numberOfFeatures(); }); When you visualize the table data with a FeatureLayer, that will automatically load the table so it can be displayed.

Online Status	Offline
Date Last Visited	‎10-27-2021 05:19 PM

My Ideas

Latest Contributions by JamesBallard1

Re: Offline map tiles from a remote server

Re: Buttons Occasionally Unresponsive After Network Request

Re: Relocation Error When running Qt Application Linking libEsriCommonQt.so

Re: Battle of the Runtimes

Re: Battle of the Runtimes

Re: Crash on iOS + MacOS with 100.12

Re: Crash on iOS + MacOS with 100.12

Re: Crash on iOS + MacOS with 100.12

Re: Extracting data from a Shapefile

Re: Extracting data from a Shapefile