CSS_COMPOSITING can be enabled on EFL port. However some tests don't have expectation.
Created attachment 258565 [details] Patch
Comment on attachment 258565 [details] Patch Attachment 258565 [details] did not pass mac-wk2-ews (mac-wk2): Output: http://webkit-queues.webkit.org/results/30804 New failing tests: fast/replaced/object-with-embed-url-param.html
Created attachment 258566 [details] Archive of layout-test-results from ews104 for mac-mavericks-wk2 The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews. Bot: ews104 Port: mac-mavericks-wk2 Platform: Mac OS X 10.9.5
Created attachment 258567 [details] Patch
Have you compared png results with Mac results? Are they same/similar? Additionally it would be great to check-in png results too, having only rendertree dumps aren't so useful for human eyes to determine if the results are correct or not.
(In reply to comment #5) > Have you compared png results with Mac results? Are they same/similar? > Additionally it would be great to check-in png results too, having only > rendertree dumps aren't so useful for human eyes to determine if the > results are correct or not. EFL layout test hasn't supported image diff officially yet. However let me check it locally. BTW it looks like you are on summer vacation. Have a nice vacation :)
Created attachment 258677 [details] Patch
(In reply to comment #5) > Have you compared png results with Mac results? Are they same/similar? > Additionally it would be great to check-in png results too, having only > rendertree dumps aren't so useful for human eyes to determine if the > results are correct or not. Actual result of png files have nothing when running css3/blending with CSS3_COMPOSITING. So I need to investigate it. Anyway I would like to land this patch(with PRIVATE OFF) as a first step in order to support CSS3_COMPOSITING. When I fix this problem, I would like to set it to PUBLIC ON. What do you think about it ?
(In reply to comment #8) > (In reply to comment #5) > > Have you compared png results with Mac results? Are they same/similar? > > Additionally it would be great to check-in png results too, having only > > rendertree dumps aren't so useful for human eyes to determine if the > > results are correct or not. > > Actual result of png files have nothing when running css3/blending with > CSS3_COMPOSITING. So I need to investigate it. Anyway I would like to land > this patch(with PRIVATE OFF) as a first step in order to support > CSS3_COMPOSITING. When I fix this problem, I would like to set it to PUBLIC > ON. What do you think about it ? Ossy ?
rs=me to add the option. But why should we add expected files for the tests if the feature is still disabled? I prefer adding them when we enable the feature.
(In reply to comment #10) > rs=me to add the option. > > But why should we add expected files for > the tests if the feature is still disabled? > I prefer adding them when we enable the feature. Added expected files are similar with mac's one. So render tree expected result seems to be correct to me. If you think it would be good to add both text and png result at a time, it is better to add png result with this patch. Let me try to fix wrong png result soon. Then I will request review again.
(In reply to comment #11) > (In reply to comment #10) > > rs=me to add the option. > > > > But why should we add expected files for > > the tests if the feature is still disabled? > > I prefer adding them when we enable the feature. > > Added expected files are similar with mac's one. So render tree expected > result seems to be correct to me. If you think it would be good to add both > text and png result at a time, it is better to add png result with this > patch. Let me try to fix wrong png result soon. Then I will request review > again. How is it possible that we have similar results with disabled CSS compositing as Mac platform with enabled CSS compositing? Something is weird here and should be investigated in details. If these tests are for testing CSS compositing feature, they should fail if the feature is disabled.
(In reply to comment #12) > (In reply to comment #11) > > (In reply to comment #10) > > > rs=me to add the option. > > > > > > But why should we add expected files for > > > the tests if the feature is still disabled? > > > I prefer adding them when we enable the feature. > > > > Added expected files are similar with mac's one. So render tree expected > > result seems to be correct to me. If you think it would be good to add both > > text and png result at a time, it is better to add png result with this > > patch. Let me try to fix wrong png result soon. Then I will request review > > again. > > How is it possible that we have similar results with disabled CSS > compositing > as Mac platform with enabled CSS compositing? Something is weird here and > should be investigated in details. The similar results were gotten when CSS compositing is enabled. As we said, png results have problem, I just wanted to add the results first.
(In reply to comment #13) > The similar results were gotten when CSS compositing is enabled. As we said, > png results have problem, I just wanted to add the results first. This patch doesn't enable CSS compositing, only adds the cmake option. Why is it useful to add expected files for enabled CSS compositing? They would fail on the bot until we enable it. (If they pass now, the tests are completely wrong and don't test CSS compositing at all.) I prefer adding expected files in the patch which enables the feature in the future.
(In reply to comment #14) > (In reply to comment #13) > > > The similar results were gotten when CSS compositing is enabled. As we said, > > png results have problem, I just wanted to add the results first. > > This patch doesn't enable CSS compositing, only adds the cmake option. As I said, it was gotten when I enabled it. But latest patch disabled it for now. > Why is it useful to add expected files for enabled CSS compositing? > They would fail on the bot until we enable it. (If they pass now, > the tests are completely wrong and don't test CSS compositing at all.) > I prefer adding expected files in the patch which enables the feature > in the future. I already agreed with your suggestion !
Closing this bug because the EFL port has been removed from trunk. If you feel this bug applies to a different upstream WebKit port and was closed in error, please either update the title and reopen the bug, or leave a comment to request this.