[FireWire]

Hi!

I'm just curious: I've been using WebKit since a long time and I run the Acid3 test after each new build to check for any improvement. One thing that is consistent is that the test always "stalls" briefly at 69/100, before resuming. Upon refresh, the test is very smooth and doesn't slow down at 69. Just out of curiosity, what exactly is happening?

[P]

Most likely it's loading something, and the next time you run it, that object is in the cache.

[Atheist]

Originally Posted by P 

Most likely it's loading something, and the next time you run it, that object is in the cache.

That's what I was thinking... maybe loading some javascript?

[FireWire]

Yeah, I figured it was loading something I'm curious as to why they never fix it, release after release? Do you know what exactly is happening at this precise moment? According to Google searches, I noticed there are several crashes at 69, and that if you click on a menu at the beginning of the test, it will stop at 69 until you release it. Very strange!

[turtle777]

Originally Posted by FireWire 

Yeah, I figured it was loading something I'm curious as to why they never fix it, release after release?

Well, duh, if it loads something (which then resides in cache), what's there to fix ?
It's just the nature of that test.

-t

[FireWire]

Here's what it says when it stalls:

Failed 0 tests.
Test 69 passed, but took 14 attempts (less than perfect).
Total elapsed time: 1.04s

So I don't think that's intended. I know it doesn't affect anything, but I think Apple should fix that, so we can boast to have a "perfect" browser.

[jay3ld]

Code:
    function () {
      // test 69: check that the support files loaded -- preparation for the rest of the tests in this bucket
      assert(!(kungFuDeathGrip == null), "kungFuDeathGrip was null");
      assert(!(kungFuDeathGrip.title == null), "kungFuDeathGrip.title was null");
      if (kungFuDeathGrip.title.length < 7)
        return "retry";
      assert(!(kungFuDeathGrip.firstChild == null), "kungFuDeathGrip.firstChild was null");
      assert(!(kungFuDeathGrip.firstChild.contentDocument == null), "kungFuDeathGrip.firstChild.contentDocument was null");
      assert(!(kungFuDeathGrip.firstChild.contentDocument.getElementsByTagName == null), "kungFuDeathGrip.firstChild.contentDocument.getElementsByTagName was null");
      var t = kungFuDeathGrip.firstChild.contentDocument.getElementsByTagName('text')[0];
      assert(!(t == null), "t was null");
      assert(!(t.parentNode == null), "t.parentNode was null");
      assert(!(t.parentNode.removeChild == null), "t.parentNode.removeChild was null");
      t.parentNode.removeChild(t);
      return 5;
    },

Not loading anything other than it appears some text in the document.

[tooki]

Originally Posted by FireWire 

Hi!

I'm just curious: I've been using WebKit since a long time and I run the Acid3 test after each new build to check for any improvement. One thing that is consistent is that the test always "stalls" briefly at 69/100, before resuming. Upon refresh, the test is very smooth and doesn't slow down at 69. Just out of curiosity, what exactly is happening?

I don't think the primary goal of Acid3 is to check loading efficiency, but rather rendering and execution accuracy.

[FireWire]

Yeah, but "our" goal should be to be "perfect" 14 attempts to pass something is, like they said, less than perfect!