February 2012 - webkit-efl - lists.webkit.org

Few change suggestions in EFL port
by Tomasz Morawski 23 Apr '12

23 Apr '12

Hello, I would like to propose changes related to some aspect of c programming style used in our EFL WebKit port that could make our port more consistent with other WebKit port like Gtk and Qt. Currently, we are trying to follow some EFL libraries programming style that hides structures declaration inside cpp files and use one single private header file. I know that it works inside EFL's libraries but the our WebKit port it is not and it will never be typical EFL's library. I think current solution doesn't work well for example: overgrown files like ewk_view.h/cpp, ewk_frame.h/cpp files and ewk_private.h file, a lot of unneeded public API that is used only by internal WebKit tools (like DRT) but it will be never uses by final user. Moreover, there is a lot of programmers that would like to cleanup this mess and have more readable port architecture. I suggest to: 1) Allow to define ewk_*_private.h files when it is needed and use it internally like Gtk, Qt port does. It is possible to use ewk_*_private.h files by internal test application: the DRT tree or other tests. 2) Move structures form cpp files to corresponding private header files (approach like Gtk and typical for c programming) 3) Move private function from ewk_private.h to corresponding private header files and delete this file (more objective) After that: 4) Simplify and remove some code that will be no need after this refactor (some code is only for handling private by force structures). 5) Reduce size of ewk_frame.h/cpp and ewk_view.h/cpp files by moving some declaration to ewk_*_private.h 6) We will follow typical for WebKit's port architecture like qt, gtk port do (they use private file widely). Due to that the port code organization will be more familiar for gtk reviewers and newcomer programmer. What you think about this? Best Regards, Tomasz Morawski

4 8

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

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

02 Feb '12

Hello ryuan, I'm sorry. I don't understand well what is your point. Anyway, if #if USE(SOUP) macro is problem, we can distinguish libsoup / libcurl file for each ewk file. For example, ewk_cookie_soup.cpp ewk_cookie_curl.cpp and so on. AS you know, ewk_auth already use this. We can select which file is built by make file. How do you think about it ? - Gyuyoung. ------- Original Message ------- Sender : ryuan Choi<ryuan.choi(a)gmail.com> Date : 2012-02-02 11:14 (GMT+09:00) Title : Re: [webkit-efl] Dropping support for the libcurl network backend Hi, guys. I'm not sure whether we can drop libcurl when libsoup is better. If I am right, ecore have options to support glib. I think that It means that glib is not mandatory on Efl world. Can we declare that webkit/efl is only available when ecore is compiled with glib? -- Ryuan Choi 2012년 2월 2일 오전 10:38, Gyuyoung Kim <gyuyoung.kim(a)samsung.com>님의 말: 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 _______________________________________________ webkit-efl mailing list webkit-efl(a)lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-efl

2 1

Dropping support for the libcurl network backend
by Raphael Kubo da Costa 01 Feb '12

01 Feb '12

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

1 0