No subject

Tue May 3 15:05:30 PDT 2016

Now I did the same but using my native x11 display with the opengl nvidia drivers. To do that, simply export the variable USE_NATIVE_XDISPLAY=1 before running the tests. I did several runs of this, storing each run in a different directory. This are the results:

 -> Run 1: Unexpected flakiness: image-only failures (159)
 -> Run 2: Unexpected flakiness: image-only failures (25)
 -> Run 3: Unexpected flakiness: image-only failures (22)

So, my conclusion is that is not caused by swrast. I can reproduce the flakiness also with the nvidia driver.

BTW, Check this results:

 - swrast:
 - nvidia run 1:
 - nvidia run 2:

As you can see. Both the expected and the actual images are different on each one of the three cases.

On the nvidia run 2, the expected result didn't even reached the point to render anything than a blank viewport.

I think that using swrast instead of hardware-backed opengl is not the problem here.

You are receiving this mail because:
You are the assignee for the bug.
Date: Tue, 30 Aug 2016 06:27:19 -0700
MIME-Version: 1.0
Content-Type: text/html

      <base href="" />
            <b><a class="bz_bug_link 
          bz_status_NEW "
   title="NEW - [GTK][Threaded Compositor] Several flaky tests"
   href="">Comment # 12</a>
              on <a class="bz_bug_link 
          bz_status_NEW "
   title="NEW - [GTK][Threaded Compositor] Several flaky tests"
   href="">bug 161242</a>
              from <span class="vcard"><a class="email" href="mailto:clopez&#64;" title="Carlos Alberto Lopez Perez &lt;clopez&#64;;"> <span class="fn">Carlos Alberto Lopez Perez</span></a>
        <pre>(In reply to <a href="show_bug.cgi?id=161242#c11">comment #11</a>)
<span class="quote">&gt; (In reply to <a href="show_bug.cgi?id=161242#c10">comment #10</a>)
&gt; &gt; Would it be possible to test on the bots without using the software
&gt; &gt; rasterizer?
&gt; Yes, please, swrast doesn't work with wayland either, because of
&gt; eglCreateImage being dummy when using the software rasterizer.
&gt; &gt; The clipping issues look as if the resizing of the underlying pixmap is not
&gt; &gt; yet complete, or as if just a part of it is rendered.
&gt; Why are we using the software path, to not depend on the bot drivers? Maybe
&gt; that's why I could never reproduce those issues. And that would explain why
&gt; all this started when switched to the threaded compositor.</span >

We use swrast because its the best way of ensuring that developers can get consistent results for the layout tests.

Otherwise it will be a nightmare. Think in developers having nvidia cards, or intel ones. With different versions of the drivers, etc.

I have tested the following:

1) Reproduce the problem. I was able to do this at the first try. The trick is run the whole test suite using the same workers as number of CPUs, which is the default. So if you want to reproduce this, don't force any number of workers and simply tun the full test suite.

I did this:
    $ Tools/Scripts/run-webkit-tests --no-show-results --no-new-test-results --no-sample-on-timeout --results-directory layout-test-results-xvfb-swrast --debug-rwt-logging --release --gtk

And I got this:
    <a href=""></a>

More information about the webkit-unassigned mailing list