- webkit-efl - lists.webkit.org

Wiki update
by Seo Sanghyeon 27 Mar '12

27 Mar '12

With introduction of jhbuild, I think our wiki page should be updated. http://trac.webkit.org/wiki/EFLWebKit Can someone responsible for jhbuild change update the wiki page? -- Seo Sanghyeon

2 1

DRT Font Init Change
by Dominik Röttsches 20 Mar '12

20 Mar '12

Hi all, since we now have the jhbuild configuration in place, I would propose we change the font loading to take the fonts from the downloaded webkitgtk-fonts directory. IMO, this further helps stabilizing test results. https://bugs.webkit.org/show_bug.cgi?id=81507 has a quick patch to illustrate the change. Feedback on how we determine the path is welcome, GTK uses an env var for WEBKIT_TOP_LEVEL. I will compare test runs before and after to get a better idea of whether we would need rebaselining after applying that change. What is your opinion on this? Thanks, Dominik

2 1

Add missing expected result set to EFL port.
by Gyuyoung Kim 14 Mar '12

14 Mar '12

Hello WebKit EFL folks, I found missing expected result set in EFL port’s layout test expected result set. As you can see below result, I could get below result when I ran layout test without *Skipped* file. 　7 DumpRenderTree crashes ( 0.1%) 13 tests timed out ( 0.1%) 1486 no expected results found (16.9%) 2742 text diff mismatch (31.2%) 36 image mismatch ( 0.4%) 871 skipped ( 9.9%) 1,486 test cases are missing in EFL expected result set. Category of missing test cases is as below, - accessibility - animations - css2.1 - css3 - editing - fast/backgrounds - fast/block - fast/borders - fast/css - fast/forms - fast/frames - fast/hidpi - fast/html - fast/images - fast/multicol - fast/regions - fast/repaint - fast/text - fast/viewport - http/tests - media - plugins - Printing - svg/W3C-SVG-1.1-SE - svg/custom In my opinion, almost test cases are being supported by EFL port. So, I would like to add these missing expected result set to LayoutTests/platform/efl directory. If there is no objection in port community, as far as I know, I can push them without reviewing. I would like to know what opinion about my suggestion. - Gyuyoung

3 4

Symbols visibility
by Tomasz Morawski 28 Feb '12

28 Feb '12

Hi, I have noticed that we have started to use linker script(Source/cmake /eflsymbols.filter) to control symbols visibility in our EFL WebKit port library. This is a content of this file: { global: ewk_*; extern "C++" { DumpRenderTreeSupportEfl*; }; local: *; }; Currently all function declaration in export “C” section is exported as visible. It does not matter if you add or not add EAPI keyword to functions header declaration. They will be exported anyway. The EAPI is just a decoration and it could be removed but I am not suggesting this solution right now. Moreover, we export a single c++ class and it is visible in our c style library symbol which is doubtful! I think we need to decidate how we will control symbols visiblity. I think linker script is not used by any other port and we should not use it. Best Regards, Tomasz Morawski

2 3

Start to run layout-test on EFL build bot.
by Gyuyoung Kim 28 Feb '12

28 Feb '12

Hello WebKit folks, Finally, EFL build bot starts to run the layout test (as well as WebKit build) from Yesterday. - url : http://build.webkit.org/builders/EFL%20Linux%20Release => Results: 19475/28486 tests passed (68.4%) => Tests to be fixed (9011): 1 DumpRenderTree crash ( 0.0%) 28 no expected results found ( 0.3%) 256 text diff mismatch ( 2.8%) 21 image mismatch ( 0.2%) 8705 skipped (96.6%) => Tests that will only be fixed if they crash (WONTFIX) (0): As you can see from the above result, pass ratio of EFL port layout test is worse than the other ports. So, WebKit EFL developers are going to submit a number of patches related to layout test. I hope that submitted patches are going to be reviewed by many reviewers as well. In addition, I’m planning to add a new server for WebKit EFL debug build. I expect the new server will be set up within next month. Cheers, Gyuyoung.

2 1

Re: [webkit-efl] Update Skipped file of EFL layout test for Ubuntu 11.10
by Gyuyoung Kim 27 Feb '12

27 Feb '12

Hello Dominik, >> Wouldn't it make sense to adopt the approach of the GTK port and to >> augment Ubuntu 11.10 with jhbuild? Yes, I agree with your suggestion. We also need to have a script like jhbuild to run layout test on same environment. >> If you let us know, we can work on >> 1) adopting JHBuild for EFL build procedure >> 2) creating a defined font configuration before runTest() I also think we should define which font we use when DRT is run. If you guys help to support above featurers, I'm willing to help your contribution. :-) Cheers, Gyuyoung. ------- Original Message ------- Sender : Dominik R?ttsches<dominik.rottsches(a)linux.intel.com> Date : 2012-02-24 17:37 (GMT+09:00) Title : Re: [webkit-efl] Update Skipped file of EFL layout test for Ubuntu 11.10 Hello Gyuyoung, as you mentioned in the previous mail: https://lists.webkit.org/pipermail/webkit-efl/2012-February/000133.html On top of Ubuntu, there's a need for quite a number of packages to be installed on top. Also, the version numbers in this list might change as we go forward with development. Wouldn't it make sense to adopt the approach of the GTK port and to augment Ubuntu 11.10 with jhbuild? Also, I am not sure whether the installation/setup of fonts on Ubuntu is a good reference. If you for example enable Korean language support in Ubuntu, it installs additional fonts which may already give different results than a vanilla Ubuntu installation in some cases. There's already a possibility for error. Don't we need to adopt some kind of font-clamping mechanism as in the GTK port of DRT which hard-resets Fontconfig to a defined state before each test? If you let us know, we can work on 1) adopting JHBuild for EFL build procedure 2) creating a defined font configuration before runTest() Regards, Dominik On 02/24/2012 08:54 AM, Gyuyoung Kim wrote: > Hello WebKit EFL folks, > > As mentioned in below mail thread, I would like to set Ubuntu 11.10 as reference platform. > https://lists.webkit.org/pipermail/webkit-efl/2012-February/000133.html > > In order to run layout test on Ubuntu 11.10, we need to update *Skipped* file because layout test exit early when fail count is above 500. > IMHO, we need to run layout test as soon as possible because it is more clear to do rebaseline by means of reference platform. > > I file a bug for this. > https://bugs.webkit.org/show_bug.cgi?id=79440 > > I got below result by Bug 79440's patch on Ubunt 11.10 and similar result is shown on EFL build bot as well. > > => Results: 19465/28451 tests passed (68.4%) > => Tests to be fixed (8986): > 239 text diff mismatch ( 2.7%) > 21 image mismatch ( 0.2%) > 8726 skipped (97.1%) > => Tests that will only be fixed if they crash (WONTFIX) (0): > > - Gyuyoung. > _______________________________________________ > webkit-efl mailing list > webkit-efl(a)lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-efl -- Dominik R?ttsches Linux Software Engineer Intel Finland Oy (OTC, SSD)

3 5

Update Skipped file of EFL layout test for Ubuntu 11.10
by Gyuyoung Kim 24 Feb '12

24 Feb '12

Hello WebKit EFL folks, As mentioned in below mail thread, I would like to set Ubuntu 11.10 as reference platform. https://lists.webkit.org/pipermail/webkit-efl/2012-February/000133.html In order to run layout test on Ubuntu 11.10, we need to update *Skipped* file because layout test exit early when fail count is above 500. IMHO, we need to run layout test as soon as possible because it is more clear to do rebaseline by means of reference platform. I file a bug for this. https://bugs.webkit.org/show_bug.cgi?id=79440 I got below result by Bug 79440's patch on Ubunt 11.10 and similar result is shown on EFL build bot as well. => Results: 19465/28451 tests passed (68.4%) => Tests to be fixed (8986): 239 text diff mismatch ( 2.7%) 21 image mismatch ( 0.2%) 8726 skipped (97.1%) => Tests that will only be fixed if they crash (WONTFIX) (0): - Gyuyoung.

1 0

WebKit EFL Layout Test Result on Ubuntu 11.10.
by Gyuyoung Kim 23 Feb '12

23 Feb '12

Hello WebKit EFL folks, I ran layout test of WebKit EFL on Ubuntu 11.10. Result of test is as below, => Results: 20,555/28,418 tests passed (72.3%) => Tests to be fixed (7,863): 2 DumpRenderTree crashes ( 0.0%) 1 test timed out ( 0.0%) 910 text diff mismatch (11.6%) 21 image mismatch ( 0.3%) 6,929 skipped (88.1%) => Tests that will only be fixed if they crash (WONTFIX) (0): - System under test 1. CPU : Intel Core i7-2600 3.4 GHz 2. RAM : 3GB 3. OS : Ubuntu 11.10 4. WebKit Rev. : r108436 I will find which packages we need to install further. It seems to me font packages may need to be installed. If so, I will let you guys know them by means of webkit-efl mailing list. To verify dependent on packages, I list up packages I installed into Ubuntu 11.10. - eina-1.1.0 - eet-1.5.0 - evas-1.1.0 - ecore-1.1.0 - embryo-1.1.0 - edje-1.1.0 - e_dbus-1.1.0 - efreet-1.1.0 - zlib1g-dev (1.2.3.4) - libjpeg8-dev (8c) - libpng12-dev (1.2.46) - libfreetype6-dev (2.4.4) - liblua5.1-0-dev (5.1.4) - libdbus-1-dev (1.4.14) - flex (2.5.35) - bison (2.4.1) - gperf (3.0.3) - cmake (2.8.5) - libcairo2-dev (1.10.2) - libsqlite3-dev (3.7.7) - libxml2-dev (2.7.8) - libxslt1-dev (1.1.26-7) - libicu-dev (4.4.2) - libsoup-2.4-dev (2.37.3) - glib (2.31) - libffi-dev (3.0.11) - gettext (0.18.1.1) - libgnome-keyring-dev (3.2.0) - libgstreamer0.10-dev (0.10.35-1) - libgstreamer-plugins-base0.10-dev (0.10.35-1) - libxext-dev (2.1.3.0) - apache2 (2.2.20) - libapache2-mod-php5 (5.3.6) - libruby (1.8.7) I update WebKitEFLLayoutTest wiki page as well. (http://trac.webkit.org/wiki/WebKitEFLLayoutTest) - Gyuyoung

1 1

Re: [webkit-efl] Dropping support for the libcurl network backend
by Gyuyoung Kim 06 Feb '12

06 Feb '12

Hello Kubo, >> I don't see performance as a single determinant factor here, but I'd >> love to see some data from your colleagues. Yes, my coworkers are going to start curl profiling vs. libsoup. If curl performance is better, we need to consider which network backend EFL port uses. If there is no difference from performance and features of view, I think it is better to use curl instead of libsoup in order to remove glib dependency. If so, my co-workers are willing to maintain libcurl port or participate in libcurl port. In addtion, we need to consider Ryuan's comment. If some guys don't want to use glib dependency, how to connect network via libsoup ? p.s Please ignore my previous email that patch receiver is wrong. BR, Gyuyoung. ------- Original Message ------- Sender : Raphael Kubo da Costa<kubo(a)profusion.mobi> Date : 2012-02-02 21:12 (GMT+09:00) Title : Re: [webkit-efl] Dropping support for the libcurl network backend Gyuyoung Kim writes: > Hello Kubo, > > I agree with your opinion that soup macro clutter is growing. However, > we don't test/profile which one is better yet. If libcurl's > performance or features are better than soup, application may want to > use libcurl instead of libsoup. > > I heard my co-workers have a plan to profile both libcurl and > libsoup. Why don't we decide if we drop libcurl after the profiling ? I don't see performance as a single determinant factor here, but I'd love to see some data from your colleagues. However, the point I'm trying to make is that even if curl's performance is currently better, I currently see more value in improving the soup backend to make it at least close to curl's performance. If you look at the commit logs for Source/WebCore/platform/network/curl, you will see it is not being actively maintained by anyone. And if you look at its sources, you will see many methods it implements are simply stubs with no functional code. Which brings us to the second point you mentioned, features: there is code in ewk which only works with the libsoup backend and there are many more features currently not implemented in the backend itself. Last but not least, if most of the people working on the EFL port are already using the libsoup backend and even the EWS bot only tests the changes in with the soup backend, I don't see the current situation changing, which means we will keep working on adding features with one backend in mind while the one just rots. -- Raphael Kubo da Costa ProFUSION embedded systems http://profusion.mobi _______________________________________________ webkit-efl mailing list webkit-efl(a)lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-efl

2 1

Re: [webkit-efl] Dropping support for the libcurl network backend
by Gyuyoung Kim 02 Feb '12

02 Feb '12

Hello Kubo, I agree with your opinion that soup macro clutter is growing. However, we don't test/profile which one is better yet. If libcurl's performance or features are better than soup, application may want to use libcurl instead of libsoup. I heard my co-workers have a plan to profile both libcurl and libsoup. Why don't we decide if we drop libcurl after the profiling ? -- Gyuyoung. ------- Original Message ------- Sender : Raphael Kubo da Costa<kubo(a)profusion.mobi> Date : 2012-02-02 01:44 (GMT+09:00) Title : [webkit-efl] Dropping support for the libcurl network backend Hi there. We've supported building webkit-efl with both the curl and libsoup network backends for quite some time. By default, the port builds with the libsoup backend, the layout tests (and the skipped list) assume the libsoup backend is used, and there is code in ewk (ewk_cookies, ewk_network and ewk_auth, for example) which only works in the soup backend. Given all that, the fact that the #if USE(SOUP) clutter is growing and the way these #ifdefs are causing bug 77341 to be more troublesome to integrate than neeed, I'm inclined to drop support for the curl backend. The only current drawback I see is that we'd force the dependency on unstable GNOME libraries for things to work. Thoughts? Does anyone desperately need the libcurl backend? -- Raphael Kubo da Costa ProFUSION embedded systems http://profusion.mobi _______________________________________________ webkit-efl mailing list webkit-efl(a)lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-efl

3 2