Category: WebKitGTK+

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.

Regarding software, we had the incredible opportunity to meet with a lot of WebKit engineers in the WebKit Contributors Meeting, it was very interesting to attend to the discussions and comment about the current situation of the project with the people there. Personally I would stress the debates about: WebKit2, Javascript engine performance and hardware acceleration drawing. I’ve also spend some time with Eric creating a version of the new-run-webkit-tests for Gtk+, I still have to check the patch and upload it. We also participated in the green bots hackathon, which allowed Gtk+ bots to enter in the core bots group, it took a little bit more time but now it should be easier to control the bots. Related with WebKit we also met some people in the bay are that are using WebKitGTK+, it is nice to check how the work we are doing is useful for those products.

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.