It would be nice to move fast/canvas/webgl/ tests out into a top-level webgl/ directory to decrease number of fast/ tests.
Created attachment 185234 [details] WIP - move webgl folder move webgl folder and modify the tests' include path (e.g. ../../js/js-test-pre.js to ../fast/js/js-test-pre.js)
Created attachment 185238 [details] WIP - modify TestExpectations Changed fast/canvas/webgl paths to webgl/ in TestExpectations
What is your opinion about this? Is it good to do this by two patches or should I create only one patch?
Created attachment 185725 [details] patch - fast/canvas/webgl movement - platform specific expectations have also been moved from fast/canvas/webgl to webgl/ - every fast/canvas/webgl reference have been replaced to webgl/ (html, js, skiplist) - removed some webgl paths from skiplists [chromium and chromium-android] because they were missing. (it's needed because of style bot)
Comment on attachment 185725 [details] patch Attachment 185725 [details] did not pass mac-wk2-ews (mac-wk2): Output: http://queues.webkit.org/results/16272112 New failing tests: webgl/read-pixels-test.html fast/images/webgl-teximage2d.html
Comment on attachment 185725 [details] patch Attachment 185725 [details] did not pass chromium-ews (chromium-xvfb): Output: http://queues.webkit.org/results/16267138 New failing tests: platform/chromium/virtual/deferred/fast/images/webgl-teximage2d.html fast/images/webgl-teximage2d.html
Created attachment 185761 [details] WIP
Comment on attachment 185761 [details] WIP Attachment 185761 [details] did not pass mac-wk2-ews (mac-wk2): Output: http://queues.webkit.org/results/16271258 New failing tests: webgl/read-pixels-test.html fast/images/webgl-teximage2d.html
Comment on attachment 185761 [details] WIP Attachment 185761 [details] did not pass chromium-ews (chromium-xvfb): Output: http://queues.webkit.org/results/16252419 New failing tests: platform/chromium/virtual/deferred/fast/images/webgl-teximage2d.html fast/images/webgl-teximage2d.html
Comment on attachment 185725 [details] patch Attachment 185725 [details] did not pass mac-ews (mac): Output: http://queues.webkit.org/results/16269319 New failing tests: fast/images/webgl-teximage2d.html
Comment on attachment 185761 [details] WIP Attachment 185761 [details] did not pass mac-ews (mac): Output: http://queues.webkit.org/results/16271439 New failing tests: fast/images/webgl-teximage2d.html
@gman is currently working on importing the Khronos WebGL conformance tests as layout tests into a new top-level webgl/ directory. I think that the existing fast/canvas/webgl/ folder should be left alone for now because most of the tests will be obsoleted. (A few are WebKit-specific tests which are not feasible to incorporate as conformance tests.)
I'd like to suggest some steps for this 1) Change disabling of tests in LayoutTests/platform/mac/TestExpectations and LayoutTests/platform/chromium/TestExpectation from the generic 'webgl' to one entry for each and every test. find WebKit/LayoutTests/webgl/conformance -name "*.html" -print should generate that list. 2) Enable each test in LayoutTests/webgl that has a corresponding, equivalent, and passing test in LayoutTests/fast/canvas/webgl 3) Delete those tests from LayoutTests/fast/canvas/webgl that were enabled in #2
(In reply to comment #13) > I'd like to suggest some steps for this > > 1) Change disabling of tests in LayoutTests/platform/mac/TestExpectations and LayoutTests/platform/chromium/TestExpectation from the generic 'webgl' to one entry for each and every test. > > find WebKit/LayoutTests/webgl/conformance -name "*.html" -print > > should generate that list. > > 2) Enable each test in LayoutTests/webgl that has a corresponding, equivalent, and passing test in LayoutTests/fast/canvas/webgl > > 3) Delete those tests from LayoutTests/fast/canvas/webgl that were enabled in #2 This sounds good. I was going to suggest trying to reduce the number of lines added to TestExpectations if we could continue to disable some entire directories, but this would be a maintenance nightmare so never mind. Let's go ahead and do this.
Is this bug/patch still valid?
ping?
(In reply to comment #16) > ping? No, this is probably obsolete. I'm closing the bug right now.