I need clarification on toFront/toBack or dev help

I'm working on a neat-o script, and one of the methods I've written creates a lot of graphics assets, collects their ids in an array, then sorts their ids by the objects' "top" property. It then steps through the array and toFront()'s each object. I end up with some weird random sorting errors where objects that I earlier toBack()'ed end up in front of some of the objects I've later toFront()'ed. I saw mentioned by Riley somewheres that calling toFront/toBack does an operation on every sortable object on the page. I'm wondering if this is the problem I'm experiencing and if there's a best practice I ought to be obeying. Otherwise, I could use the keen eye of a developer to see if there's something better or I could implement or perhaps evaluate if this is actually a bug in the API that needs reporting.

Welp, here's the part of the code that does the trick: wallCollection.sort(function(a, b){ return getObj("graphic", a).get("top") - getObj("graphic", b).get("top") }); for(i = 0; i < wallCollection.length; i++){ tile = getObj("graphic", wallCollection[i]); toFront(tile); log(tile.get("top")); } The log() call shows me that these graphics are being processed in their properly by-top sorted order. Almost all of them leap to the front in the expected order, which I tested by simple selection tests and deleting until I got to the bottom (from an arrangement that I could visually parse.) Two or three objects from the set, which are wall objects, got stuck behind floors which were toBack()'ed in a previous method call and aren't connected logically in any way. Is there something about the synchronicity that I don't know about? PS - I'm researching race conditions. And also, the objects that fail the ordering commands do so consistently. So it's not random objects missing their ordering, the problems happen the same way every time I test it.

I had the same issue with the random depth script I wrote. I had to spread the updates across time with setTimeout() to actually get them to change appropritely: <a href="https://gist.github.com/shdwjk/0a14b06ef4da1cb5e33" rel="nofollow">https://gist.github.com/shdwjk/0a14b06ef4da1cb5e33</a>...

Apparently I never hit Submit Post when last I was in here. But I wanted reiterate that if I reproduce the starting conditions before running the script, the sorting fails in the same way every time. I would think this would point to an issue in my code, and I found some cases I need to account for... but they are not related to the most egregious sorting errors-- where I get toBack()'ed floors getting in front of toFront()'ed walls (and I found one case where a toBack()'ed floor was both in front of and behind two different toFront()'ed wall pieces that shared the same graphic asset, top value, and sorting.) Thanks for looking into it. This is mostly an aesthetics problem that doesn't block further development on my part.

Riley D. said: That was going to be my next suggestion as well :-) When I'm in the API stuff next week I'll take a look at how we're handling updating object properties to see if we can tackle this better without that workaround. I'm pretty sure I know what might be causing the issue. Great! =D

Jonathan S. said: Apparently I never hit Submit Post when last I was in here. But I wanted reiterate that if I reproduce the starting conditions before running the script, the sorting fails in the same way every time. I would think this would point to an issue in my code, and I found some cases I need to account for... but they are not related to the most egregious sorting errors-- where I get toBack()'ed floors getting in front of toFront()'ed walls (and I found one case where a toBack()'ed floor was both in front of and behind two different toFront()'ed wall pieces that shared the same graphic asset, top value, and sorting.) Thanks for looking into it. This is mostly an aesthetics problem that doesn't block further development on my part. Most Javascript virtual machines are inherently single threaded. Additionally the speed of execution will generally be constant for the same block of code with the same initial conditions. That means the result in most cases will be deterministic. i.e.: In general, it will fail the same way for the same input with the same code. =D

The Aaron said: Most Javascript virtual machines are inherently single threaded. Additionally the speed of execution will generally be constant for the same block of code with the same initial conditions. That means the result in most cases will be deterministic. i.e.: In general, it will fail the same way for the same input with the same code. =D Right... as I would expect. ...unless there were race conditions? Anyway, yeah-- I'm trying to say that it might be an issue with how toFront/toBack is implemented without actually saying that I think it's buggy... cause then i'd look like an idiot when I figure out what's wrong with my code over a bowl of cereal next week :P

Was this bug fixed? I'm experiencing it consistently with newly created objects, although I'm also doing the prod server hack to avoid errors with modifying newly created objects.