Latest Contributions by XavierIrias

I had the same issue when upgrading. Clearly the domReady event is firing prematurely, before dojo is fully ready. I just changed dojo.byId to window.getElementById to get around that bug. ... View more

Well, it's not as boiled down as I would like but unfortunately the very, very simple cases don't seem to fail as much.  Here is a fiddle that shows the problem.  esri javascript 4.10 - JSFiddle  What you should see is a nice rendering of the Irish grid, a 5x5, that redraws when you pan or zoom.  Instead you sometimes see just fragments of the grid, other times you see it draw flawlessly. it seems to be data-dependent. To make the behavior vanish you can comment out the Array.prototype.remove lines at the top of the javascript section.  Very odd, as I said this code never gets called but its presence plus an as-yet-unidentified data characteristic seems to trigger the bug. I've found that refreshing the page yields different results, implying that possibly the WebGL system carries state from one refresh to the next. ... View more

I did some further testing.  The graphics clipping in 4.10 seems to happen if and only if Array.prototype.remove is polyfilled. I don't know why but removing the polyfill made the issue disappear in Chrome on OSX.  I also tested with some console.log calls to see if my polyfill was even being called, and it's not.  So it's not the content of the polyfill for .remove but its mere presence that makes version 4.10 fail, so perhaps version 4.10 is property-sniffing and is thrown off by the presence of a .remove member on Array?  Very odd but it seems highly repeatable so I thought it might be helpful for you to know. ... View more

Okay, I'm a little closer to resolving this one.  I had a polyfill for Array.prototype.remove which seems to be incompatible with version 4.10 of the API.  Removing the polyfill solved the problem ( I think ).   So as  a guess, version 4.10 is conditionally polyfilling this same function but with a different implementation.  The one that was not compatible returns a new array with the indicated element removed.  Possibly version 4.10 returns the same array but with an item removed and gets confused if array is new. ... View more

Netta, I share your suspicion that the root cause of your issue is the same as my issue.  Unfortunately I don't yet have a trivial example showing the error but it's definitely true that version 4.10 is truncating graphics where 4.9 does not.  Also 4.10 is prone to hanging when given a large amount of graphics to draw, such that I have to kill the browser tab.  So far I have observed these problems with Firefox and Chrome on OSX. It should be possible to disable WebGL on the browser (rather than asking the Esri API to not use it).  I will attempt to do so and report back since that would be a smoking gun implicating the webGL code. ... View more

Solution found:  I traced the problem to inclusion of Yahoo YUI version 2.81, specifically a single css file: <link rel="stylesheet" type="text/css" href="../yui/reset-fonts-grids/reset-fonts-grids.css" >         When I remove that line, or replace it with an include of  reset-fonts.css, the ESRI API works correctly in Firefox.   So clearly the grids css from YUI is causing some problems for ESRI.  This is true regardless of whether the ESRI stylesheet tundra.css is before or after the YUI sheet. ... View more

I too can't get the API 1.6 or 2.0 to work correctly with Firefox.  Wondering if anyone in the dev group is aware that Firefox doesn't work with the newer API's... ... View more

When you use wkid 102100, and read points from the map, you will get values for x and y in a cartesian reference rather than geographic coordinates, and as noted the Javascript ESRI API provides convenience methods to convert to and from.  So far so good. However, the calcs within the API seem to actually use the wrong WKID.  WKID 102100 is supposed to incorporate eccentricity, as opposed to the "old" WKID 102113, the spherical version.  According to the article "Migrating map tiling schemes" on the ESRI Resource Center, ArcGIS online services are now hosted in 102100 because it's "better".  True enough, but when I test the actual conversions performed by the Javascript API, in fact they seem to still be using the spherical equations.  This does not make a huge difference but it's enough to notice, and enough to throw your calcs out of whack when you're trying to debug.  I added the two spatial references to my converter utility so you can test this and other calcs out.  See http://ersquared.org:8080/marconitest/map/convert.jsp On the left side, put in lat and long (remember longitude is negative in the US), choosing WGS84 as the datum.  On the right side, for destination coordinates, choose Web Mercator.  But then try the calc using WGS84 as the datum, and then the WGS84 spherical (as used in WDID 102113).  You will see that the spherical numbers are an exact match with the ESRI Javascript libraries, while the ellipsoidal version differs slightly. I entered the various WKID parameters and did calcs, etc. in the hope that my problems had to do with wkid.  But they turned out to be far larger, so large that finetuning WKID is somewhat like arranging deck chairs on the Titanic, as long as fundamental browser problems exist.  As things stand now, I still can't place markers in the correct spot with Firefox.  I'm curious if you're using MSIE only, and that's why you can even notice other more subtle problems. ... View more

The Javascript version ought to be best.  Reading and parsing XML ought to be lightning fast in a modern browser even for thousands of items.  The bottleneck is likely in making the graphics not in parsing the xml.  I suggest profiling your javascript code, either with a tool, or with simple timer calls. If the data change very seldom, make sure that your browser is caching the results.  You can verify this with Firebug. Other things to consider:  1. consider using JSON instead of XML.  It's smaller and quicker to evaluate; most browsers have JSON parsing done natively now. 2. examine all your looping code and optimize it by moving initialization items outside the loop.  I know, standard procedure, but if you profile you may find you're creating objects, parsing strings, etc. hundreds of times instead of just once. 3. make sure that you are not concatenating large strings with Javascript.  This type of operation absolutely does not scale linearly (it's far worse).  If you need to build a large string, use an array then do a single array.join operation at the end.  4. generally manipulate objects prior to attaching to the DOM, not after. ... View more