v2.2 GraphicsLayer doesn't always draw graphics in correct order

Question

We're trying to upgrade from ESRI silverlight api 2.1 to 2.2.  We have a graphicsLayer which contains several polylines as well as several PictureMarkerSymbols.  We always add the polylines to the layer BEFORE we add the symbols.  This has always resulted in the symbols being drawn on top of the polylines.  When we upgraded to 2.2, we noticed that although things seem to be drawn correctly initially, if the user then pans the map so that a symbol with polylines under it moves off the screen TO THE RIGHT and then pans the map to move the symbol back on screen, sometimes the polylines are now drawn on top of the symbol (note that I don't think this is some sort of video card bug, because I can now get at the tool tip for the polyline, whereas before, when the symbol was on top of it, I couldn't.)  This problem persists until the user pans the map so that the same symbol moves off the screen TO THE LEFT and then pans the map to move the symbol back on screen; at that point, the symbol is again properly drawn on top.
 
It seems like this is a bug added in v2.2, because the graphics are documented to draw in the order created (from Graphic.GetZIndex() method):
 
"...By default all Graphic objects in a GraphicCollecton have a Z-Index value of zero (0) unless specifically set in either code-behind or XAML....If no Z-Index value has ever been set, Graphics are drawn on the Map in the order that they are created in code-behind or XAML. This means the first Graphic in the GraphicCollection is drawn first and the process repeats itself until the last Graphic in the GraphicCollection is draw." (sic.)
 
We're not setting the ZIndex of any graphics, but I did add code to check this value for each graphic after it is added to the layer, and they are all zero.
 
I know I can perhaps add things I want on top to a different layer, but that makes zooming to show all graphics harder, etc.  
 
Can ESRI please confirm this is a bug (or perhaps a bug in my understanding)  If this is a bug, is there a fix?
 
Thank you!

AndySanford · Answer

Hi, Morten,
 
Thanks so much for your reply!
 
You say "the order that the graphics are added in, is NOT necessarilythe order they are rendered in..." I have two comments in regard to this:
 
1) The ESRI API reference for Graphic.SetZIndex() method seems to contradictyour statement, but perhaps the doc is incorrect or I am misunderstandingsomething.
 
2) Regardless of the documentation, I am certain we've seen the behaviorchange I described going from 2.1 to 2.2, and it is extremely easy to demo, atleast on my machine (you know how that goes!) I even just made a local copy ofthe demo I previously attached, and the only difference (besides the map's newwraparound property, which I just set to false) between the two (that I'm awareof) is one uses the esri 2.1 dll, and the other uses the esri 2.2 dll. I ranfrom the debugger, and between each run I cleared IE and download caches, thereproduced the different behavior, and before exiting the debugger, I brokeinto the debugger and verified the expected esri dll module was being used. The2.1 version worked as the I and the API doc described (graphics always drawn inthe order added, even when panning on/off/on screen), and the 2.2 versionexhibited the changed behavior as I previously described (draws in the correctorder originally, but after panning the graphics in question off the screen andthen back on in various directions - top, bottom, left, right - the drawingorder gets reversed.) I guess this could just be some strange behavior from my machine,but that seems suspect.  Can youreproduce this change in behavior?  
 
3) In regard to your comment about layers vs. explicit zindex setting: inour case, the zindex setting is actually a better workaround than layers.Something I noticed is that this problem behavior not only impacts differentgraphic object types (polylines vs symbols) in a layer, but also impacts thedrawing order between different graphics of the same type (for example, polylines)in the same layer.  We draw manypolylines, and sometimes they can partially overlap, and are sometimes in differentcolors.  The problem behavior thus causesthe apparent rendering of the lines to change as the user pans objects on andback on screen; parts of lines originally obscured pop to the top, and then popback to the back.  This makes ourapplication�??s rendering non-deterministic, which gives a poor impression.  It is of course not practical for us to putevery polyline in a different layer, and it may not be reasonable to make surethat no lines overlap.  So, we workedaround the problem for now by incrementing the zindex for each object as we addit to the layer (ob1.z=0, ob2.z=1, ob3.z=2, etc.)
 
I�??d be curious to hear what you think about these points.  Thanks so much for your time, and an overallgreat, easy-to-use and powerful product!
 
Regards,
 
-Andy

SomeGISGuy · Answer

The order that the graphics are added in, is NOT necessarily the order they are rendered in (although many times that can seem like what is happening).
If you want your points to show up on top of your lines, you should create two layers: One layer for points and one layer for lines, and keep them separate. The order is always guaranteed between layers.
You could set the Z Index on the graphic to 1 for all points, but it's cleaner to keep them in two separate layers (this also makes the layers work better with a renderer).
Of zoom is an issue, you can easily join the extents of the two layers and zoom to that instead, using the envelope.Union(otherEnvelope) method.

Btw. this behavior didn't change between v2.1 and v2.2. It's been like this all the way back to v1.0beta 🙂

AndySanford · Answer

The attached file will show the problem; it is a modified verison of your sample:
http://help.arcgis.com/en/webapi/silverlight/samples/start.htm#AddGraphicsXAML
 
Basically, you will start with a line drawn over the circle. If you pan the map so the circle leaves the screen via the bottom, and then pan back, you will now see the circle drawn over the line. 
 
The same problem happens even amongst two overlapping polylines drawn in the same layer. BTW, I did find that if I increment the zindex of each graphic I add to a layer, it will avoid the 2.2 bug, but I don't know what side effects or performance impacts that will have.

MainPage.zip

buffer_problem_1.jpg