- In 2011, when I wrote my last post I was working on WebKit2 stuff, I was helping to create the initial parts of the GTK+ code. Our goal was to prove it was the best way to spend our time if we wanted to improve graphical result, and I’m glad to say we were right. If you test Epiphany WebKit2 it is easy you check the differences. Now better developers than me are taking care of that work and we are getting a good multiprocess engine.
- We started working in the accelerated compositing for WebKitGTK+, after some initial tests and decisions nowadays we have a fairly complete solution with TextureMapper. The implementation includes a fallback cairo backend and the OpenGL one, it even works in WebKit2. We are trying to push this work as much as we can in order to have it integrated as the GNOME 3.6 graphical solution. WebGL is also working in both versions of the API and even video acceleration is among our goals for this release.
- We added WebKit2 test support and we are now passing 27000 tests, that is an amazing figure. Phil made a great effort to rationalize the use of our bots and we have now a good solution.
- We released WebKitGTK 1.8 for GNOME 3.4 and we started the 1.9 cycle. And after this time it is still a painful task to do, good thing that now Carlos takes care to keep dist-check working.
- We started helping with cairo-gl multisampling compositor, our plan is WebKit integration, this library and last changes in accelerated compositing are good foundations to create a great user experience in any device. There has been good feedback from the WebKitEFL people. They are using this backend in Tizen browser with very good results.
- Awesome Martin and me talked in the last desktop summit (Berlin) about WebKit2GTK+ current situation of the engine and future work. We introduced some work we have done this last year, I think we get the picture mostly right.
- I attended another WebKitGTK+ hackfest in A Coruña, it was great to meet old and new collaborators of the project. We spent a lot of time with accelerated compositing at that point.
- Last year some guys decided to nominate me as a WebKit reviewer and other nice guys backed the proposal.
- In 2012 I had the opportunity to attend the last WebKit meeting in Cupertino, it is really amazing how many interesting things are being developed around the technology and the possibilities we have in the future for a platform like this. I like San Francisco and it is always great to come back every year.
Also in the last year we celebrated Igalia’s 10th anniversary, the truth is that we started working on the project in the beginning of 2001, so I have been working here for more than 11 years already. We use the legal date to celebrate it for technical reasons. It has been a very long trip already, and I feel I’ve changed a lot because all the experiences we had, good and bad. Best thing is that I was able to work in a challenging project with great people, and learn a lot from them.
I think that was all for the wrap-up, probably I’m missing something someone will remind me, sorry about it Internet. I almost forgot, another interesting experience was the time off I had in the beginning of this year, for a little bit more than one month, it was a good way to celebrate the 10 years working.
The 3.6 release is going to bring the WebKit2 support and we will try to have Epiphany integration ready at that point, that would close a great development cycle. I’ll try to blog more from now on and give more information about this (/me smiles), probably explaining some of that work more in detail would make a lot of sense.
By the way, I’ll attend GUADEC this year again, see you there.
On April several developers from our team had the chance to attend the WebKit contributors meeting in Cupertino, I’ve spent a couple of more days in San Francisco to take advantage of the long trip and spend some time hacking with Martin and Xan.
It is always a good moment to catch up with the people in the WebKit community and think about your position and motivation in the project. I would like to thank the Apple team for making it happen. We talked about WebKit2, not all the decisions are made and things like C API could change its design in the future, stay tuned. We are pushing WebKit2GTK+ and now it is more complete and it is easier to contribute to. We even have landed the test runner patch, and now running tests is possible.
We also did some hacking, fixed some issues in WebKitGTK and prepared 1.4.0 release, the new stable release that includes most of the work we have done the last year. All the tests that are passing now have made this new stable release a better library, it is easy to realize about it after spending some time using the browser. It is clear that software needs taking care of the small details, if you want someone to use it, and that takes time and effort. Our team in Igalia has made a good work creating the best WebKitGTK+ release so far. We have come from a big file with skipped tests to more than 22.000 tests passed and that is a huge difference that the final user can check.
I hope more people can enjoy the software and contribute to the code, this is one of the reasons free software rocks.
After some months of cleaning, fixing and landing all the required patches (some provided by Motorola devs), yesterday we landed the last one adding the shared memory support, so you can safely download and compile WebKit2 with GTK+ using the trunk of the WebKit svn. Just add –enable-webkit2 to the compilation configuration of your choice and you’ll get a small MiniBrowser implemented with WebKit2 C API.
Basic feature of this new API is that it uses a split process architecture, the UI is separated from the web content in a different process. It means a lot of pros and some cons, currently at Igalia we are ready to face the cons so we can get all the pros, creating more stable and responsive applications using the port. Our plan is to add the complete support and make Epiphany work with it at some point.
We are also adding WebKitTestRunner support which will help a lot with the development. Besides the C API we are implementing a GTK+ friendly API, basically we are using the WebKit1 API over the WebKit2 C API, so you can even test it with the GtkLauncher and your own GNOME application easily.
The code and APIs are still development status, there is still a lot of work to do, so just use them for testing purposes, this is just the initial step and we hope after this a lot of people can contribute to make the port rock even more.
It has been a very intense week, we are all tired but I think all the energy spent in the work and discussions during this week has paid off in the end. We have worked in a lot of topics: rendering (performance, leaks, WebGL patches), cleaning tests and bots, networking, JSC, Epiphany, a11y support, gstreamer, plugins, etc.. And we have crossed off a lot of things from the TODO list.
Thanks to everybody that helped to make this real and see you all the next year.
In this post I’ll be talking about the shadows rendering in WebKitGTK+. If you are not interested in the details skip the rest of the post, the summary is: yes, shadows are not a problem anymore in the usual cases for WebKitGTK+, and we plan to improve even more the situation.
CSS, SVG and HTML5 Canvas specifications allow to render shadows around elements. This is a small mess, as all the three standards did not pay much attention to each other when defining about the shadows API, so now we have different APIs and some confusion for the implementors. We could check it after having to solve some issues in the current blur algorithm, actually I even proposed a change to the HTML5 spec trying to help clarifying it. The main problem with these shadows is that huge boxes could add visually nice offset shadows, like what happens in identi.ca, causing huge computations to blur a big rectangle as the recommended algorithm basically approximates a gaussian blur using 3 box blurs. Gtk and Qt ports use the SVG implementation of this algorithm, coded inside WebKit because neither cairo nor Qt implement this filter; Chrome/Skia does less box blurs, it is faster but it gets poorer results in my opinion. Firefox also uses the 3 box blurs as recommended in SVG and tries to reduce the area as much as possible using clipping.
When we profiled this problem we could easily spot a couple of issues that could be solved: the algorithm is using C++ objects instead of accessing directly to the pixels to operate, and it is copying the surfaces in memory more than required. A patch fixing these issues showed a big improvement, that is nice but still not enough to get good user experience. Calculating the destination value for every pixel is still very costly for huge rectangles, so the best option seemed to be to try to avoid the blurring as much as possible instead of just improving the algorithm. The options: clipping and reducing even more using a smaller shadow to create a big one using tiling (for rectangles which are the main use case). We created both patches both patches but after the tests the result was that just the tiling one was enough to fix the main uses cases like identi.ca, even with the issues in the blur algorithm and not clipping, the reduction in those cases fixed the main issue we were trying to fix. Of course we are interested in those patches and we are working to integrate a better algorithm because we want all the shadows to work better.
By the way, our WebKit team in Igalia has defined a wiki with our goals with regard to rendering, you can check them and propose us other ideas or discuss them, we are very interested in your experience and feedback using WebKitGTK+
Last week was a very interesting week for our WebKit group in Igalia, a lot of things happened, we even found that a volcano explosion did not allow Philippe to come back from San Francisco, hopefully he will make it at the end of this week. Luckily enough Juanjo, Xan and me have tickets for one of the few airports not closed in Europe.
I’ve also attended the Linux Collaboration Summit (just after the WebKit Meeting), it was not a bad experience, Google gave us a Nexus One after all. I was at the MeeGo workgroup where Nokia and Intel presented their agendas for the platform. I also was at the Desktop workgroup, the main topic was desktop technologies and the integration with Internet services, it is going to be interesting to check how the desktop will evolve to integrate Internet services, and what role free software plays in that environment.
Of course I have to mention I really enjoyed the city, we did not have much time but Martin helped us to discover very nice places and food.
Lately I’ve been checking the rendering code in WebKitGTK+, graphics are always very challenging. We want to check how to improve scrolling and rendering in general. Maybe some of the points are interesting for someone else or maybe you can send me some feedback about them:
- I’ve used cairo-trace and cairo-perf-trace to check the performance of different backends doing a usual short browsing session (open slashdot and scroll) with Epiphany. I wanted to add Skia to the test because I wanted to compare with Chrome backend. Cairo Skia backend does not look well maintained, I had to change some code in order to compile it, but it worked eventually. The results are interesting because shows that Xlib backend is faster (probably accelerated operations) than Skia and Skia is a little bit faster than the Cairo image backend but quite similar, both probably running on the CPU:
[ # ] backend test min(s) median(s) stddev. count [ 0] null epiphany 0.644 0.652 2.06% 6/6 [ 0] gl epiphany 7.121 8.770 8.91% 15/15 [ 0] skia epiphany 2.106 2.110 0.11% 5/6 [ 0] xlib epiphany 1.874 1.903 1.41% 5/6 [ 0] image epiphany 2.154 2.180 1.09% 6/6 [ 0] image16 epiphany 3.721 3.752 0.59% 6/6
If this is correct we have to look inside WebKit for improvements, which means we have to review the rendering process carefully.
- After checking the patches for the tiled backing store I’ve implemented a tiled backing store for WebKitGTK+ in a branch of a local repository in Igalia. It still has some pending work (graphic context not correctly used in forms, frames are not supported, threading, resizes, etc.). Results regarding performance are not the expected ones but it works and we can check the performance, conclusion is still not clear, blit is fast but we need to improve the tiles rendering. I think we have to be very sure that we are improving the situation when adding complex code, so there is still work here to show it makes sense.
I would like to add that cairo-trace is an awesome tool, Cairo people deserve a lot of kudos for implementing it. I will use cairo-trace to check the tiled backing store and how the solution of the form controls rendering behaves with regard to performance.
Regarding the other part of the topic, next week some of us will be in San Francisco for the Webkit meeting, we will also attend the Linux Collaboration Summit and meet some people there; so if you are in the bay area and you want to have a drink just sent us an email. With the last WebKit2 announcement I think it would be a very interesting meeting.
I almost forgot, our WebKit team in Igalia has grown and we have more motivated people working with us (currently Xan, Philippe, Sergio, Mario, Juanjo and me, and Diego doing his internship), this is good because we could work in more interesting topics inside the project.
After the hackfest and the Christmas holidays we continued working in the GNOME browser, it is hard but someone has to do it :-P. I wanted to do a small summary because in this time without blogging a lot of things happened and I think sharing the report could be interesting for other people.
The roadmap for 2.30 is waiting just for the soup on-disk cache (Dan is working in this one), so currently we are doing some cleaning work in Epiphany, addressing the current regressions, Diego has joined the group to help with it. Xan did an awesome work finishing the DOM bindings, this patch should be the beginning of the work in this topic in order to have complete bindings. Of course Philippe has been working in the multimedia support adding nice features like the on-disk buffering. Millan is helping also us with the a11y support and on this regard I’m still waiting for a review of the bug 25676 which is required for the caret browsing.
Trying to solve some a11y issues I’ve changed the WebKitGTK+ tooltips support to get rid of some of the work-arounds that it had, now it uses the GtkTooltip API. Regarding the a11y requirements we still have some limitations to position the tooltip that it is not clear how we could solve.
I’ve been also trying to finish some refactoring of the load states inside Epiphany, hopefully now it would be easier to deal with that code.
I wrote this summary initially as a personal report of our work and felt it was nice to share it, this way I can create more interesting posts than using just my work ;). It is also nice to check the interest of other people and companies using WebKitGTK+ in their desktop and in their products.
My interests these weeks are Cody’s GtkOffscreenWindow widget and the DOM bindings, I was wondering also about the visual result of the scrolling in Epiphany, it has some tearing and I think we could do it better. Really interesting things to check :).
After the last hours hacking, it is a good moment to comment a little bit about the week spent in the hackfest. I’m quite happy with the result of the organization done by Igalia, although I’m not the best one to give an unbiased opinion about it. Regarding the development and after checking the list of things we wrote the first day in the agenda it looks like we were able to work in a lot of the points and fix some of them. It was a good week for the projects WebKitGTK+ and Epiphany, thanks to the veeery long days of hacking,
Xan posted a good summary of the work we have done this week, I would like to add we worked in the a11y, we have uploaded a patch to fix the caret browsing and we have proposed the change in the tooltips implementation, trying to solve a problem. I have also finished the cache API patches and added a workaround to the test of the middle click paste so we could upload the patch, and other misc patches. A very interesting week indeed, we have to repeat it. In the TODO list I would like to point out some topics for the next months:
- DOM bindings
- Gecko regressions in Epiphany
- libsoup disk cache
- multimedia stuff
In Igalia we would like to work in these points in the next months, if you are interested in other topics and you want to propose something to us (Igalia), just contact us, any support or suggestions are welcome.
Kudos to all the people that help in this awesome project.