Bug 59839 - [chromium] Layout test animations/3d/replace-filling-transform.html failing
Summary: [chromium] Layout test animations/3d/replace-filling-transform.html failing
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: 528+ (Nightly build)
Hardware: PC OS X 10.5
: P2 Normal
Assignee: James Robinson
URL:
Keywords:
Depends on: 59149
Blocks:
  Show dependency treegraph
 
Reported: 2011-04-29 15:30 PDT by Kenneth Russell
Modified: 2011-05-03 14:48 PDT (History)
6 users (show)

See Also:


Attachments
Patch (2.89 KB, patch)
2011-05-02 19:54 PDT, James Robinson
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Kenneth Russell 2011-04-29 15:30:14 PDT
http://trac.webkit.org/changeset/85338 added layout test animations/3d/replace-filling-transform.html which appears to be failing on all Chromium platforms. See:

http://test-results.appspot.com/dashboards/flakiness_dashboard.html#group=%40ToT%20-%20chromium.org&tests=animations%2F3d%2Freplace-filling-transform.html

Suppressing this failure for the moment.
Comment 1 Dean Jackson 2011-04-30 01:23:15 PDT
I tried to make this a platform independent pixel test. The strange thing about the bad actual results linked is that you're only seeing the red square. A failure should display both some red and green.

It's as if the green square is being composited below the red square. Is this with your hardware compositor enabled?
Comment 2 Dean Jackson 2011-04-30 01:26:08 PDT
To be more clear about the test: the green square should animate and end up in the same location as the red square. The green should cover the red. A failure in the test should still show the entire green rectangle, just with some red visible.

The fact that you see only red suggests the red is being drawn over the green.
Comment 3 Kenneth Russell 2011-05-02 19:08:26 PDT
Presumably this test is running with the hardware compositor enabled on Chromium.
Comment 4 James Robinson 2011-05-02 19:51:44 PDT
(In reply to comment #3)
> Presumably this test is running with the hardware compositor enabled on Chromium.

Aha, that's the issue - it is not running with the compositor enabled in chromium!  We only run the tests enumerated here in the chromium gpu configuration:

http://trac.webkit.org/browser/trunk/Tools/Scripts/webkitpy/layout_tests/port/chromium_gpu.py#L75

and we only skip the tests enumerated here in the chromium non-gpu configuration: 

http://trac.webkit.org/browser/trunk/LayoutTests/platform/chromium/test_expectations.txt#L285

We should update both to be aware of the fact that animations/3d/... is only useful when run with the compositor enabled.
Comment 5 James Robinson 2011-05-02 19:54:45 PDT
Created attachment 92041 [details]
Patch
Comment 6 James Robinson 2011-05-02 19:55:16 PDT
This should do the trick.
Comment 7 Dirk Pranke 2011-05-02 22:45:08 PDT
the python patch looks correct to me.
Comment 8 Kenneth Russell 2011-05-03 11:26:10 PDT
Comment on attachment 92041 [details]
Patch

Looks good to me.
Comment 9 James Robinson 2011-05-03 11:43:50 PDT
Comment on attachment 92041 [details]
Patch

Clearing flags on attachment: 92041

Committed r85628: <http://trac.webkit.org/changeset/85628>
Comment 10 James Robinson 2011-05-03 11:43:54 PDT
All reviewed patches have been landed.  Closing bug.
Comment 11 Dean Jackson 2011-05-03 12:58:39 PDT
Out of interest, do you ignore 3d transforms when you don't have HW compositing? Technically, the test should have worked with or without compositing - there wasn't anything really 3d about it. I just used a translate3d(something, something, 0) in order to trigger HW on the Apple engine.
Comment 12 James Robinson 2011-05-03 14:48:00 PDT
(In reply to comment #11)
> Out of interest, do you ignore 3d transforms when you don't have HW compositing? Technically, the test should have worked with or without compositing - there wasn't anything really 3d about it. I just used a translate3d(something, something, 0) in order to trigger HW on the Apple engine.

It should just be ignored.  Technically, this test was passing before - it was showing up as a failure just because the shade of green that chromium renders is slightly different from the baseline.  However, it seems more reasonable to run the animations/3d/ tests with our compositor enabled since that's what our users will experience.