[PATCH] [TEST] make Element#getDimensions works with display:none ancestors

Maybe it would also make sense to "null" this "huge" styles array before returning value?

The garbage collector should get to that

I really like this patch but am concerned about performance:

ancestors -> reject -> each -> each

is just a little too much for such common method, don't you think? : )

It could be turned into 2x each

ancestors -> each( fill up styles with invis. ) -> each

The downside af that is you also have to pass along all the visible elements again in the 2nd each when you set the styles back. I wonder what's the difference in performance compared to having reject filter things out, making the array smaller. Suggestions?

I suggest to change recursivelyCollect (which affects ancestors and couple of other methods) to accept iterator (which in this case could be !Element.visible)

  recursivelyCollect: function(element, property, iterator) {
    element = $(element);
    var elements = [], iterator = iterator || function(){ return true; };
    while (element = element[property])
      if (element.nodeType == 1 && iterator(element))
        elements.push(Element.extend(element));
    return elements;
  }
...
element.ancestors(Element.visible);
element.nextSiblings(function(el){ return el.hasClassName('foo') });

That's a nice idea, I wonder how that performs so I did some tests with all implementations.

I also wrote the patch again without reject and avoided the downside I mentioned earlier using an extra array. It's about 20% faster then my previous patch.

The extra functionality comes with a price, but I think getting the results you expected is worth that extra bit of time. These tests where done using up to 4 display:none ancestors, in a real setup I don't expect that much display:none ancestors, but the more you have of those, the slower it gets.

500 x Element#getDimensions test:

Without reject:
IE: 156ms - 383ms - 2.4x slower
FF: 113ms - 287ms - 2.5x slower

With reject:
IE: 156ms - 467ms - 3.0x slower
FF: 147ms - 433ms - 2.9x slower

recursivelyCollect with iterator:
IE: 159ms - 473ms - 3.0x slower
FF: after 1 cycle of 60 tests firefox freezes

Well, the with/without reject tests are pretty much what I expected. Not sure why recursivelyCollect freezes FF - I'll take a look at it.

Turns out I forgot something, after using your patch from #11143 it worked.

Added a patch to use with kangax' recursivelyCollect and created a page where the 3 methods can be timed/tested

Out of the three I prefer recursivelyCollect.

A patch with performance improvements. Based on Szymon Wilkołazki's suggestion in the spinnofs mailing list, uses #11143

Makes sure the speed will remain the same as is now for visible elements, giving less speed only when required.