## January 05, 2014

### Funding MathML Developments in Gecko and WebKit (part 2)

#### Frédéric Wang

As I mentioned three months ago, I wanted to start a crowdfunding campaign so that I can have more time to devote to MathML developments in browsers and (at least for Mozilla) continue to mentor volunteer contributors. Rather than doing several crowdfunding campaigns for small features, I finally decided to do a single crowdfunding campaign with Ulule so that I only have to worry only once about the funding. This also sounded more convenient for me to rely on some French/EU website regarding legal issues, taxes etc. Also, just like Kickstarter it's possible with Ulule to offer some "rewards" to backers according to the level of contributions, so that gives a better way to motivate them.

As everybody following MathML activities noticed, big companies/organizations do not want to significantly invest in funding MathML developments at the moment. So the rationale for a crowdfunding campaign is to rely on the support of the current community and on the help of smaller companies/organizations that have business interest in it. Each one can give a small contribution and these contributions sum up in enough money to fund the project. Of course this model is probably not viable for a long term perspective, but at least this allows to start something instead of complaining without acting ; and to show bigger actors that there is a demand for these developments. As indicated on the Ulule Website, this is a way to start some relationship and to build a community around a common project. My hope is that it could lead to a long term funding of MathML developments and better partnership between the various actors.

Because one of the main demand for MathML (besides accessibility) is in EPUB, I've included in the project goals a collection of documents that demonstrate advanced Web features with native MathML. That way I can offer more concrete rewards to people and federate them around the project. Indeed, many of the work needed to improve the MathML rendering requires some preliminary "code refactoring" which is not really exciting or immediately visible to users...

Hence I launched the crowdfunding campaign the 19th of November and we reached 1/3 of the minimal funding goal in only three days! This was mainly thanks to the support of individuals from the MathML community. In mid december we reached the minimal funding goal after a significant contribution from the KWARC Group (Jacobs University Bremen, Germany) with which I have been in communication since the launch of the campaign. Currently, we are at 125% and this means that, minus the Ulule commision and my social/fiscal obligations, I will be able to work on the project during about 3 months.

I'd like to thank again all the companies, organizations and people who have supported the project so far! The crowdfunding campaign continues until the end of January so I hope more people will get involved. If you want better MathML in Web rendering engines and ebooks then please support this project, even a symbolic contribution. If you want to do a more significant contribution as a company/organization then note that Ulule is only providing a service to organize the crowdfunding campaign but otherwise the funding is legally treated the same as required by my self-employed status; feel free to contact me for any questions on the project or funding and discuss the long term perspective.

Finally, note that I've used my savings and I plan to continue like that until the official project launch in February. Below is a summary of what have been done during the five weeks before the holiday season. This is based on my weekly updates for supporters where you can also find references to the Bugzilla entries. Thanks to the Apple & Mozilla developers who spent time to review my patches!

## Collection of documents

The goal is to show how to use existing tools (LaTeXML, itex2MML, tex4ht etc) to build EPUB books for science and education using Web standards. The idea is to cover various domains (maths, physics, chemistry, education, engineering...) as well as Web features. Given that many scientific circles are too much biased by "math on paper / PDF" and closed research practices, it may look innovative to use the Open Web but to be honest the MathML language and its integration with other Web formats is well established for a long time. Hence in theory it should "just work" once you have native MathML support, without any circonvolutions or hacks. Here are a couple of features that are tested in the sample EPUB books that I wrote:

• Rendering of MathML equations (of course!). Since the screen size and resolution vary for e-readers, automatic line breaking / reflowing of the page is "naturally" tested and is an important distinction with respect to paper / PDF documents.
• CSS styling of the page and equations. This includes using (Web) fonts, which are very important for mathematical publishing.
• Using SVG schemas and how they can be mixed with MathML equations.
• Using non-ASCII (Arabic) characters and RTL/LTR rendering of both the text and equations.
• Interactive document using Javascript and <maction>, <input>, <button> etc. For those who are curious, I've created some videos for an algebra course and a lab practical.
• Using the <video> element to include short sequences of an experiment in a physics course.
• Using the <canvas> element to draw graphs of functions or of physical measurements.
• Using WebGL to draw interactive 3D schemas. At the moment, I've only adapted a chemistry course and used ChemDoodle to load Crystallographic Information Files (CIF) and provide 3D-representation of crystal structures. But of course, there is not any problem to put MathML equations in WebGL to create other kinds of scientific 3D schemas.

## WebKit

I've finished some work started as a MathJax developer, including the maction support requested by the KWARC Group. I then tried to focus on the main goals: rendering of token elements and more specifically operators (spacing and stretching).

• I improved LTR/RTL handling of equations (full RTL support is not implemented yet and not part of the project goal).
• I improved the maction elements and implemented the toggle actiontype.
• I refactored the code of some "mrow-like" elements to make them all behave like an <mrow> element. For example while WebKit stretched (some) operators in <mrow> elements it could not stretch them in <mstyle>, <merror> etc Similarly, this will be needed to implement correct spacing around operators in <mrow> and other "mrow-like" elements.
• I analyzed more carefully the vertical stretching of operators. I see at least two serious bugs to fix: baseline alignment and stretch size. I've uploaded an experimental patch to improve that.
• Preliminary work on the MathML Operator Dictionary. This dictionary contains various properties of operators like spacing and stretchiness and is fundamental for later work on operators.
• I have started to refactor the code for mi, mo and mfenced elements. This is also necessary for many serious bugs like the operator dictionary and the style of mi elements.
• I have written a patch to restore support for foreign objects in annotation-xml elements and to implement the same selection algorithm as Gecko.

## Gecko

I've continued to clean up the MathML code and to mentor volunteer contributors. The main goal is the support for the Open Type MATH table, at least for operator stretching.

• Xuan Hu's work on the <mpadded> element landed in trunk. This element is used to modify the spacing of equations, for example by some TeX-to-MathML generators.
• On Linux, I fixed a bug with preferred widths of MathML token elements. Concretely, when equations are used inside table cells or similar containers there is a bug that makes equations overflow the containers. Unfortunately, this bug is still present on Mac and Windows...
• James Kitchener implemented the mathvariant attribute (e.g used by some tools to write symbols like double-struck, fraktur etc). This also fixed remaining issues with preferred widths of MathML token elements. Khaled Hosny started to update his Amiri and XITS fonts to add the glyphs for Arabic mathvariants.
• I finished Quentin Headen's code refactoring of mtable. This allowed to fix some bugs like bad alignment with columnalign. This is also a preparation for future support for rowspacing and columnspacing.
• After the two previous points, it was finally possible to remove the private "_moz-" attributes. These were visible in the DOM or when manipulating MathML via Javascript (e.g. in editors, tree inspector, the html5lib etc)
• Khaled Hosny fixed a regression with script alignments. He started to work on improvements regarding italic correction when positioning scripts. Also, James Kitchener made some progress on script size correction via the Open Type "ssty" feature.
• I've refactored the stretchy operator code and prepared some patches to read the OpenType MATH table. You can try experimental support for new math fonts with e.g. Bill Gianopoulos' builds and the MathML Torture Tests.

MathML developments in Chrome or Internet Explorer is not part of the project goal, even if obviously MathML improvements to WebKit could hopefully be imported to Blink in the future. Users keep asking for MathML in IE and I hope that a solution will be found to save MathPlayer's work. In the meantime, I've sent a proposal to Google and Microsoft to implement fallback content (alttext and semantics annotation) so that authors can use it. This is just a couple of CSS rules that could be integrated in the user agent style sheet. Let's see which of the two companies is the most reactive...

## December 11, 2013

### WebKitGTK+ hackfest 5.0 (2013)!

#### Gustavo Noronha

For the fifth year in a row the fearless WebKitGTK+ hackers have gathered in A Coruña to bring GNOME and the web closer. Igalia has organized and hosted it as usual, welcoming a record 30 people to its office. The GNOME foundation has sponsored my trip allowing me to fly the cool 18 seats propeller airplane from Lisbon to A Coruña, which is a nice adventure, and have pulpo a feira for dinner, which I simply love! That in addition to enjoying the company of so many great hackers.

Web with wider tabs and the new prefs dialog

The goals for the hackfest have been ambitious, as usual, but we made good headway on them. Web the browser (AKA Epiphany) has seen a ton of little improvements, with Carlos splitting the shell search provider to a separate binary, which allowed us to remove some hacks from the session management code from the browser. It also makes testing changes to Web more convenient again. Jon McCan has been pounding at Web’s UI making it more sleek, with tabs that expand to make better use of available horizontal space in the tab bar, new dialogs for preferences, cookies and password handling. I have made my tiny contribution by making it not keep tabs that were created just for what turned out to be a download around. For this last day of hackfest I plan to also fix an issue with text encoding detection and help track down a hang that happens upon page load.

Martin Robinson and Dan Winship hack

Martin Robinson and myself have as usual dived into the more disgusting and wide-reaching maintainership tasks that we have lots of trouble pushing forward on our day-to-day lives. Porting our build system to CMake has been one of these long-term goals, not because we love CMake (we don’t) or because we hate autotools (we do), but because it should make people’s lives easier when adding new files to the build, and should also make our build less hacky and quicker – it is sad to see how slow our build can be when compared to something like Chromium, and we think a big part of the problem lies on how complex and dumb autotools and make can be. We have picked up a few of our old branches, brought them up-to-date and landed, which now lets us build the main WebKit2GTK+ library through cmake in trunk. This is an important first step, but there’s plenty to do.

Hackers take advantage of the icecream network for faster builds

Under the hood, Dan Winship has been pushing HTTP2 support for libsoup forward, with a dead-tree version of the spec by his side. He is refactoring libsoup internals to accomodate the new code paths. Still on the HTTP front, I have been updating soup’s MIME type sniffing support to match the newest living specification, which includes specification for several new types and a new security feature introduced by Internet Explorer and later adopted by other browsers. The huge task of preparing the ground for a one process per tab (or other kinds of process separation, this will still be topic for discussion for a while) has been pushed forward by several hackers, with Carlos Garcia and Andy Wingo leading the charge.

Jon and Guillaume battling code

Other than that I have been putting in some more work on improving the integration of the new Web Inspector with WebKitGTK+. Carlos has reviewed the patch to allow attaching the inspector to the right side of the window, but we have decided to split it in two, one providing the functionality and one the API that will allow browsers to customize how that is done. There’s a lot of work to be done here, I plan to land at least this first patch durign the hackfest. I have also fought one more battle in the never-ending User-Agent sniffing war, in which we cannot win, it looks like.

Hackers chillin’ at A Coruña

I am very happy to be here for the fifth year in a row, and I hope we will be meeting here for many more years to come! Thanks a lot to Igalia for sponsoring and hosting the hackfest, and to the GNOME foundation for making it possible for me to attend! See you in 2014!

## October 30, 2013

#### Surfin’ Safari

Co-written by Beth Dakin and Mihnea-Vlad Ovidenie

CSS regions are an exciting technology that make it easier than ever to create rich, magazine-like layouts within web content. Regions have been under development in WebKit for a while now, and we’re delighted to tell you that they are available for use in Safari on iOS 7, Safari 7 on Mavericks, and Safari 6.1 on Mountain Lion.

Magazine-like layout

So I wrote this little article for my personal blog:

That’s cool and all, but wouldn’t it be so much cooler if it had a more interesting layout like this?

So fab! Without regions, achieving a layout like this is a pain. You have to figure out exactly which parts of the article can fit into each box and then hard-code the article content into the appropriate boxes. And after all that work, the design will get totally messed up if the user changes the font size! The layout looks cool, but doing it this way is a lot of work, and it isn’t even a little bit flexible.

Regions make achieving this layout as easy as pie. They allow authors to indicate that some sections of content are intended to define an overall layout template for a portion of the document and that other sections of markup represent the content that is intended to fill that template. The semantically-related content that will flow through the template is called a “named flow.” In our example above, the named flow is the text of my article. Once it has been named, the named flow is distributed into disjointed containers called regions, which can be positioned in any way to achieve the desired layout.

Our simple example only scratches the surface of what you can do with regions. We’ll get to more sophisticated applications later, but first let’s take a closer look at the code.

What is a named flow?

A named flow is a collection of HTML elements extracted from the document’s normal flow and displayed separately. Any HTML element can be part of a named flow. When an element is collected in a named flow, all of its children are collected with it.

You identify a collection of HTML elements as a named flow by using the CSS property -webkit-flow-into. In our example, the named flow will be the elements that contain the text of our article:

<style>
#flow-content { -webkit-flow-into: pizza-manifesto; }
</style>
<div id=”flow-content”><h1>Pizza is amazing</h1>...</div>

Our example only has one, but a document can have any number of named flows, each with its own name.

Flowing into regions

A region is a block-level element that displays content from a named flow instead of its own content. Regions can have any size and can be positioned anywhere in the document. They are not required to be siblings or to be positioned next to each other in the layout.

A region consumes content from a single named flow. Most of the time, to achieve an interesting layout, there will be more than one region associated with a named flow, and when that is the case those regions form a region chain. When content from a named flow does not fit into a region, the content simply flows into the next region in the chain.

Making an element a region is as easy as adding the -webkit-flow-from CSS property. In our example, the regions are the elements that form the layout template for the document’s overall design:

<style>
.region { -webkit-flow-from: pizza-manifesto; }
</style>
<div class="region" id="region-1"></div>
<img src="pizza.jpg" width=512 height=342>
<div class="region" id="region-2"></div>
<div class="region" id="region-3"></div>
<div class="region" id="region-4"></div>
<div class="region" id="region-5"></div>

Take a look at the code for the actual document to see the code for the regions side-by-side with the code for the named flow.

One key thing to remember about regions is that they are only visual containers. Region elements do not become the DOM parents of the elements flowed inside them; they only establish the bounding boxes that visually constrain the flow content.

One cool feature in the CSS Regions specification is region styling. With region styling, a designer can style the content based on which region it ends up flowing through. For example, if you wanted to change the color of the text displayed in the second region of the article flow, you could do so with region styling:

<style>
@-webkit-region #region-2 {
p { color: green; }
}
</style>

The extra styles are dynamically applied behind the scenes whenever the layout of the article content in the regions changes. So for example, if the user resizes the browser window and different pieces of content end up flowing through the styled region, the content will update dynamically. At this time, you can only style regions with the CSS properties color and background-color, but we intend to progressively add support for more properties, so stay tuned! In the meantime, check out this version of our article that uses region styling.

There is also a whole object model available for interacting with regions and named flows from within JavaScript. The proposed API will make it even easier to create fluid designs that adapt to layout changes. For example, authors can use the API to determine whether or not there are enough regions to display the content from the named flow. Handy stuff!

Dreaming with regions

CSS regions are powerful, and when they are combined with other advanced CSS features like shapes, filters, flexible boxes, transforms, and media queries, incredibly sophisticated designs can emerge.

Back in February, during a CSS regions pattern rodeo hosted by CodePen, Tyler Fry and Joshua Hibbert created some awesome regions demos. Tyler won the contest with his reading carousel made out of regions and transforms, and Joshua created an exploding book, featuring a nice hover effect when opening the book.

The Adobe WebPlatform team has created some very compelling demos with regions in partnership with National Geographic. Check out this article that seamlessly integrates text and photographs to create a flexible design. Adobe has also created a demo that is so cutting edge you will need to download a WebKit Nightly to view it properly. This beautiful prototype uses regions, so the article content breaks up automatically across the different containers, and if font size or window size changes, or if the user zooms in, everything reflows automatically. Check out the source code here!

We are so excited about regions as a technology and excited that they are already available for use in shipping browsers. We plan to continue to refine our implementation in WebKit and to add additional features, so be sure to check back for improvements.

## October 15, 2013

### Funding MathML Developments in Gecko and WebKit

#### Frédéric Wang

update 2013-10-15: since I got feedback, I have to say that my funding plan is independent of my work at MathJax ; I'm not a MathJax employee but I have an independent contractor status. Actually, I already used my business to fund an intern for Gecko MathML developments during Summer 2011 :-)

## Retrospect

Since last April, I have been allowed by the MathJax Consortium to dedicate a small amount of my time to do MathML development in browsers, until possibly more serious involvement later. At the same time, we mentioned this plan to Google developers but unfortunately they just decided to drop the WebKit MathML code from Blink, making external contributions hard and unwelcome...

Hence I have focused mainly on Gecko and WebKit: You can find the MathML bugs that have been closed during that period on bugzilla.mozilla.org and bugs.webkit.org. For Gecko, this has allowed me to finish some of the work I started as a volunteer before I was involved full-time in MathJax as well as to continue to mentor MathML contributors. Regarding WebKit, I added a few new basic features like MathML lengths, <mspace> or <mmultiscripts> while I was getting familiar with the MathML code and WebKit organization/community. I also started to work on <semantics> and <maction>. More importantly, I worked with Martin Robinson to address the design concerns of Google developers and a patch to fix these issues finally landed early this week.

However, my progress has been slow so as I mentioned in my previous blog post, I am planning to find a way to fund MathML developments...

## Why funding MathML?

Note: I am assuming that the readers of this blog know why MathML is important and are aware of the benefits it can bring to the Web community. If not, please check Peter Krautzberger's Interview by Fidus Writer or the MozSummit MathML slides for a quick introduction. Here my point is to explain why we need more than volunteer-driven development for MathML.

First the obvious thing: Volunteer time is limited so if we really want to see serious progress in MathML support we need to give a boost to MathML developments. e-book publishers/readers, researchers/educators who are stuck outside the Web in a LaTeX-to-PDF world, developers/users of accessibility tools or the MathML community in general want good math support in browsers now and not to wait again for 15 more years until all layout engines catch up with Gecko or that the old Gecko bugs are fixed.

There are classical misunderstandings from people thinking that non-native MathML solutions and other polyfills are the future or that math on the Web could be implemented via PNG/SVG images or Web Components. Just open a math book and you will see that e.g. inline equations must be correctly aligned with the text or participate in line wrapping. Moreover we are considering math on the Web not math on paper, so we want it to be compatible with HTML, SVG, CSS, Javascript, Unicode, Bidi etc and also something that is fast and responsive. Technically, this means that a clean solution must be in the core rendering engine, spread over several parts of the code and must have strong interaction with the various components like the HTML5 parser, the layout tree, the graphic and font libraries, the DOM module, the style tree and so forth. I do not see any volunteer-driven Blink/Gecko/WebKit feature off the top of my head that has this characteristic and actually even SVG or any other kind of language for graphics have less interaction with HTML than MathML has.

The consequence of this is that it is extremely difficult for volunteers to get involved in native MathML and to do quick progress because they have to understand how the various components of the Blink/Gecko/WebKit code work and be sure to do things correctly. Good mathematical rendering is already something hard by itself, so that is even more complicated when you are not writing an isolated rendering engine for math on which you can have full control. Also, working at the Blink/Gecko/WebKit level requires technical skills above the average so finding volunteers who can work with the high-minded engineers of the big browser companies is not something easy. For instance, among the enthusiastic people coming to me and willing to help MathML in Gecko, many got stuck when e.g. they tried to build the Firefox source or do something more advanced and I never heard back from them. In the other direction, Blink/Gecko/WebKit paid developers are generally not familiar with MathML and do not have time to learn more about it and thus can not always provide a relevant review of the code, or they may break something while trying to modify code they do not entirely understand. Moreover, both the volunteers and paid staff have only a small amount of time to do MathML stuff while the other parts of the engine evolve very quickly, so it's sometimes hard to keep everything in sync. Finally, the core layout engines have strong security requirements that are difficult to satisfy in a volunteer-driven situation...

## Beyond volunteer-driven MathML developments

At that point, there are several options. First the lazy one: Give up with native math rendering, only focus on features that have impact on the widest Web audience (i.e. those that would allow browser vendors to get more market share and thus increase their profit), thank the math people for creating the Web and kindly ask them to use whatever hacks they can imagine to display equations on the Web. Of course as a Mozillian, I think people must decide the Web they want and thus exclude this option.

Next there is the ingenuous option: Expect that browser companies will understand the importance of math-on-the-Web and start investing seriously in MathML support. However, Netscape and Microsoft rejected the <MATH> tag from the 1995 HTML 3.0 draft and the browser companies have kept repeating they would only rely on volunteer contributions to move MathML forward, despite the repeated requests from MathML folks and other scientific communities. So that option is excluded too, at least in the short to medium term.

So it remains the ambitious option: Math people and other interested parties must get together and try to fund native MathML developments. Despite the effort of my manager at MathJax to convince partners and raise funds, my situation has not changed much since April and it is not clear when/if the MathJax Consortium can take the lead in native MathML developments. Given my expertise in Gecko, WebKit and MathML, I feel the duty to do something. Hence I wish to reorganize my work time: Decrease my involvement in MathJax core in order to increase my involvement in Gecko/WebKit developments. But I need the help of the community for that purpose. If you run a business with interest for math-on-the-Web and are willing to fund my work, then feel free to contact me directly by mail for further discussion. In the short term, I want to experiment with Crowd Funding as discussed in the next section. If this is successful we can think of a better organization for MathML developments in the long term.

## Crowd Funding

Wikipedia defines Crowd funding as "the collective effort of individuals who network and pool their money, usually via the Internet, to support efforts initiated by other people or organizations". There are several Crowd Funding platforms with similar rule/interface. I am considering Catincan which is specialized in Open Source Crowd Funding, can be used by any backer/developer around the world, can rely on Bugzilla to track the bug status and seems to have good process to collect the fund from backers and to pay developers. You can easily login to the Catincan Website if you have a GitHub, Facebook or Google account (apparently Persona is not supported yet...). Finally, it seems to have a communication interface between backers and developers, so that everybody can follow the development on the funded features.

One distinctive feature of catincan is that only well-established Open Source projects can be funded and only developers from these projects can propose and work on the new features ; so that backers can trust that the features will be implemented. Of course, I have been working on Gecko, WebKit and MathML projects so I hope people believe I sincerely want to improve MathML support in browsers and that I have the skills to do so ;-)

As said in my previous blog post, it is not clear at all (at least to me) whether Crowd Funding can be a reliable method, but it is worth trying. There are many individuals and small businesses showing interest in MathML, without the technical knowledge or appropriate staff to improve MathML in browsers. So if each one fund a small amount of money, perhaps we can get something.

One constraint is that each feature has 60 days to reach the funding goal. I do not have any idea about how many people are willing to contribute to MathML and how much money they can give. The statistical sample of projects currently funded is too small to extract relevant information. However, I essentially see two options: Either propose small features and split the big ones in small steps, so that each catincat submission will need less work/money and improvements will be progressive with regular feedback to backers ; or propose larger features so they look more attractive and exciting to people and will require less frequent submissions to catincat. At the beginning, I plan to start with the former and if the crowd funding is successful perhaps try the latter.

## Status in Open Source Layout Engines

Note: Obviously, Open Source Crowd Funding does not apply to Internet Explorer, which is the one main rendering engine not mentioned below. Although Microsoft has done a great job on MathML for Microsoft Word, they did not give any public statement about MathML in Internet Explorer and all the bug reports for MathML have been resolved "by design" so far. If you are interested in MathML rendering and accessibility in Internet Explorer, please check Design Science blog for the latest updates and tools.

Note: I am actually focusing on the history of Chromium here but of course there are other Blink-based browsers. Note that programs like QtWebEngine (formerly WebKit-based) or Opera (formerly Presto-based) lost the opportunity to get MathML support when they switched to Blink.

Alex Milowski and François Sausset's first MathML implementation did not pass Google's security review. Dave Barton fixed many issues in that implementation and as far as I know, there were not any known security vulnerabilities when Dave submitted his last version. MathML was enabled in Chrome 24 but Chrome developers had some concerns about the design of the MathML implementation in WebKit, which indeed violated some assumptions of WebKit layout code. So MathML was disabled in Chrome 25 and as said in the introduction, the source code was entirely removed when they forked.

Currently, the Chromium Dashboard indicates that MathML is shipped in Firefox/Safari, has positive feedback from developers and is an established standard ; but the Chromium status remains "No active development". If I understand correctly, Google's official position is that they do not plan to invest in MathML development but will accept external contributions and may re-enable MathML when it is ready (for some sense of "ready" to be defined). Given the MathML story in Chrome, it seems really unlikely that any volunteer will magically show up and be willing to submit a MathML patch. Incidentally, note the interesting work of the ChromeVox team regarding MathML accessibility: Their recent video provides a good overview of what they achieve (where Volker Sorge politely regrets that "MathML is not implemented in all browsers").

Although Google's design concerns have now been addressed in WebKit, one most serious remark from one Google engineer is that the WebKit MathML implementation is of too low quality to be shipped so they just prefer to have no MathML at all. As a consequence, the best short term strategy seems to be improving WebKit MathML support and, once it is good enough, to submit a patch to Google. The immediate corollary is that if you wish to see MathML in Chrome or other Blink-based browsers you should help WebKit MathML development. See the next section for more details.

chromatic

Actually, I tried to import MathML into Blink one day this summer. However, there were divergences between the WebKit and Blink code bases that made that a bit difficult. I do not plan to try again anytime soon, but if someone is interested, I have published my script and patch on GitHub. Note there may be even more divergences now and the patch is certainly bit-rotten. I also thought about creating/maintaining a "Chromatic" browser (Chrome + mathematics) that would be a temporary fork to let Blink users benefit from native MathML until it is integrated back in Blink. But at the moment, that would probably be too much effort for one person and I would prefer to focus on WebKit/Gecko developments for now.

### WebKit

The situation in WebKit is much better. As said before, Google's concerns are now addressed and MathML will be enabled again in all WebKit releases soon. Martin Robinson is interested in helping the MathML developments in WebKit and his knowledge of fonts will be important to improve operator stretching, which is one of the biggest issue right now. One new volunteer contributor, Gurpreet Kaur, also started to do some work on WebKit like support for the *scriptshifts attributes or for the <menclose> element. Last but not least, a couple of Apple/WebKit developers reviewed and accepted patches and even helped to fix a few bugs, which made possible to move development forward.

When he was still working on WebKit, Dave Barton opened bug 99623 to track the top priorities. When the bugs below and their related dependencies are fixed, I think the rendering in WebKit will be good enough to be usable for advanced math notations and WebKit will pass the MathML Acid 1 test.

• Bug 44208: For example, in expression like $\mathrm{sin}\left(x\right)$, the "x" should be in italic but not the "sin". This is actually slightly more complicated: It says when the default mathvariant value must be normal/italic. mathvariant is more like the text-transform CSS property in the sense that it remaps some characters to the corresponding mathematical characters (italic, bold, fraktur, double-struck...) for example $\mathfrak{A}$ (mathvariant=fraktur A) should render exactly the same as $𝔄$ (U+1D504). By the way, there is the related bug 24230 on Windows, that prevents to use plane 1 characters. The best solution will probably be to implement mathvariant correctly. See also Gecko's ongoing work by James Kitchener below.
• Bug 99618: Implement <mmultiscripts>, that allows expressions like ${}_{6}{}^{14}\mathrm{C}$ or $R_{i}{}_{j}{}_{;}{}^{j}=\frac{1}{2}S_{;}{}_{i}$. As said in the introduction, this is fixed in WebKit Nightly.
• Bug 99614: Support for stretchy operators like in ${\left(\frac{\overline{{z}_{1}+{z}_{2}}}{3}\right)}^{4}$. Currently, WebKit can only stretch operators vertically using a few Unicode constructions like ⎛ (U+239B) + ⎜ (U+239C) + ⎝ (U+239D) for the left parenthesis. Essentially only similar delimiters like brackets, braces etc are supported. For small sizes like $\left(\text{}$ or for large operators like $\sum {n}^{2}$ it is necessary to use non-unicode glyphs in various math fonts, but this is not possible in WebKit MathML yet. All of this will require a fair amount of work: implementing horizontal stretching, font-specific stuff, largeop/symmetric properties etc
• Bug 99620: Implement the operator dictionary. Currently, WebKit treats all the operators the same way, so for example it will use the same 0.2em spacing before and after parenthesis, equal sign or invisible operators in e.g. $f\left(x\right)={x}^{2}$. Instead it should use the information provided by the MathML operator dictionary. This dictionary also specifies whether operators are stretchy, symmetric or largeop and thus is related to the previous point.
• Bug 119038: Use the code for vertical stretchy operators to draw the radical symbols in roots like $\sqrt{\frac{2}{3}}$. Currently, WebKit uses graphic primitives which do not give a really good rendering.
• Bug 115610: Implement <mspace> which is used by many MathML generators to do some spacing in mathematical formulas. As said in the introduction, this is fixed in WebKit Nightly.

In order to pass the Mozilla MathML torture tests, at least displaystyle and scriptlevel must be implemented too, probably as internal CSS properties. This should also allow to pass Joe Java's MathML test, although that one relies on the infamous <mfenced> that duplicates the stretchy operator features and is implemented inconsistently in rendering engines. I think passing the MathML Acid 2 test will require slightly more effort, but I expect this goal to be achievable if I have more time to work on WebKit:

• Bug 115610: Implement <mspace>. Fixed!
• Bug 120164: Implement negative spacing for <mspace> (I have an experimental patch).
• Bug 85730: Implement <mpadded>, which is also used by MathML generators to do some tweaking of formulas. I have only done some experiments, that would be a generalization of <mspace>
• Bug 85733: Implement the href attribute ; well I guess the name is explicit enough to understand what it is used for! I only have some experimental patch here too. That would be mimicing what is done in SVG or HTML.
• Bug 120059 and bug 100626: Implement <maction> (at least partially) and <semantics>, which have been asked by long-time MathML users Jacques Distler and Michael Kohlhase. I have patches ready for that and this could be fixed relatively soon, I just need to find time to finish the work.

In general passing the MathML Acid 2 test is not too hard, you merely only need to implement those few MathML elements whose exact rendering is clearly defined by the MathML specification. Passing the MathML Acid 3 test is not expected in the medium term. However, the score will naturally increase while we improve WebKit MathML implementation. The priority is to implement what is currently known to be important to users. To give examples of bugs not previously mentioned: Implementing menclose or fixing various DOM issues like bugs 57695, 57696 or 107392.

More advanced features like those mentioned in the next section for Gecko are probably worth considering later (Open type MATH, linebreaking, mlabeledtr...). It is worth noting that Apple has already done some work on accessibility (with MathML being readable by VoiceOver in iOS7), authoring and EPUB (MathML is enabled in WebKit-based ebook readers and ibooks-author has an integrated LaTeX-to-MathML converter).

### Gecko

In general I think I have a good relationship with the Mozilla community and most people have respect for the work that has been done by volunteers for almost 15 years now. The situation has greatly improved since I joined the project, at that time some people claimed the Mozilla MathML project was dead after Roger Sidge's departure. One important point is that Karl Tomlinson has worked on repairing the MathML support when Roger Sidge left the project. Hence there is at least one Mozilla employee with good knowledge of MathML who can review the volunteer patches. Another key ingredient is the work that has recently been made by Mozilla to increase engagement of the volunteer community like good documentation on MDN, the #Introduction channel, Josh Matthews' mentored bugs and of course programs like GSOC. However, as said above, it is one thing to attract enthusiastic contributors and another thing to get long-term contributors who can work independently on more advanced features. So let's go back to my latest Roadmap for the Mozilla MathML Project and see what has been accomplished for one year:

• Font support: Dmitry Shachnev created a Debian package for the MathJax fonts and Mike Hommey added MathJax and Asana fonts in the list of suggested packages for Iceweasel. The STIX fonts have also been updated in Fedora and are installed by default on Mac OS X Lion (10.7). For Linux distributions, it would be helpful to implement Auto Installation Support. The bug to add mathematical fonts to Android has been assigned in June but no more progress has happened so far. Henri Sinoven opened a bug for FirefoxOS but there has not been any progress there either. I had some patches to restore the "missing MathML fonts" warning (using an information bar) but it was refused by Firefox reviewers. However, the code to detect missing MathML font could still be used for the similar bug 648548, which also seems inactive since January. There are still some issues on the MathJax side that prevent to integrate Web fonts for the native MathML output mode. So at the moment the solution is still to inform visitors about MathML fonts or to add MathML Web fonts to your Web site. Khaled Hosny (font and LaTeX expert) recently updated my patches to prepare the support for Open Type fonts and he offered to help on that feature. After James Kitchener's work on mathvariant, we realized that we will probably need to provide Arabic mathematical fonts too.
• Spacing: Xuan Hu continued to work on <mpadded> improvements and I think his patch is close to be accepted. Quentin Headen has done some progress on <mtable> before focusing on his InstantBird GSOC project. He is still far from being able to work on mtable@rowspacing/columnspacing but a work around for that has been added to MathJax. I fixed the negative space regression which was missing to pass the MathML Acid 2 test and is used in MathJax. Again, Khaled Hosny is willing to help to use the spacing of the Open Type MATH, but that will still be a lot of work.
• <mlabeledtr>: A work around for native MathML has been added in MathJax.
• Linebreaking: No progress except that I have worked on fixing a bug with intrinsic width computation. The unrelated printing issues mentioned in the blog post have been fixed, though.
• Operator Stretching: No progress. I tried to analyze the regression more carefully, but nothing is ready yet.
• Tabular elements: As said above, Quentin Headen has worked a bit on cleaning up <mtable> but not much improvements on that feature so far.
• Token elements: My patch for <ms> landed and I have done significant progress on the bad measurement of intrinsic width for token elements (however, the fix only seems to work on Linux right now). James Kitchener has taken over my work on improving our mathvariant support and doing related refactoring of the code. I am confident that he will be able to have something ready soon. The primes in exponents should render correctly with MathJax fonts but for other math fonts we will have to do some glyph substitutions.
• Dynamic MathML: No progress here but there are not so many bugs regarding Javascript+MathML, so that should not be too serious.
• Documentation: It is now possible to use MathML in code sample or directly in the source code. The MathML project pages have been entirely migrated to MDN. Also, Florian Scholz has recently been hired by Mozilla as a documentation writer (congrats!) and will in particular continue the work he started as a volunteer to document MathML on MDN.

I apologize to volunteers who worked on bugs that are not mentioned above or who are doing documentation or testing that do not appear here. For a complete list of activity since September 2012, Bugzilla is your friend. There are two ways to consider the progress above. If you see the glass half full, then you see that several people have continued the work on various MathML issues, they have made some progress and we now pass the MathML Acid 2 test. If you see the glass half empty, then you see that most issues have not been addressed yet and in particular those that are blocking the native MathML to be enabled in MathJax: bug 687807, bug 415413, the math font issues discussed in the first point, and perhaps linebreaking too. That is why I believe we should go beyond volunteer-driven MathML developments.

Most of the bugs mentioned above are tested by the MathML Acid 3 tests and we will win a few points when they are fixed. Again, passing MathML Acid 3 test is not a goal by itself so let's consider what are the big remaining areas it contains:

• Improving Tabular Elements and Operator Stretching, which are obviously important and used a lot in e.g. MathJax.
• Linebreaking, which as I said is likely to become fundamental with small screens and ebooks.
• Elementary Mathematics (you know addition, subtraction, multiplication, and division that kids learn), which I suspect will be important for educational tools and ebooks.
• Alignment: This is the one part of MathML that I am not entirely sure is relevant to work on in the short term. I understand it is useful for advanced layout but most MathML tools currently just rely on tables to do that job and as far as I know the only important engine that implements that is MathPlayer.

Finally there are other features outside the MathML rendering engines that I also find important but for which I have less expertise:

• Transferring MathML that is implementing copy/cut/drag and paste. Currently, we can do that by treating MathML as normal HTML5 code or by using the "show MathML source" feature and copying the source code. However, it would be best to implement a standard way to communicate with other MathML applications like Microsoft Word, Mathematica, Mapple, Windows' Handwriting panel etc I wrote some work-in-progress patches last year.
• Authoring MathML: Essentially implementing things like deletion, insertion etc maybe simple MathML token creation ; in Gecko's core editor, which is used by BlueGriffon, KompoZer, SeaMonkey, Thunderbird or even MDN. Other things like integrating Javascript parsers (e.g. ASCIIMath) or equation panels with buttons like are probably better done at the higher JS/HTML/XUL level. Daniel Glazman already wrote math input panels for BlueGriffon and Thunderbird.
• MathML Accessibility: This is one important application of MathML for which there is strong demand and where Mozilla is behind the competitors. James Teh started some experimental work on his NVDA tool before the summit.
• EPUB reader for FirefoxOS (and other mobile platforms): During the "Co-creating Action Plans" session, the Mozilla Taipei people were thinking about missing features for FirefoxOS and this idea about EPUB reader was my modest contribution. There are a few EPUB readers relying on Gecko and it would be good to check if they work in FirefoxOS and if they could be integrated by default, just like Apple has iBooks. BTW, there is a version of BlueGriffon that can edit EPUB books.

## Conclusion

I hope I have convinced some of the readers about the need to fund MathMLin browsers. There is a lot of MathML work to do on Gecko and WebKit but both projects have volunteers and core engineers who are willing to help. There are also several individuals / companies relying on MathML support in rendering engines for their projects and could support the MathML developments in some way. I am willing to put more of my time on Gecko and WebKit developments, but I need financial help for that purpose. I'm proposing catincan Crowd Funding in the short term so that anyone can contribute at the appropriate level, but other alternatives to fund the MathML development can be found like asking Peter Krautzberger about native MathML funding in MathJax, discussing with Igalia about funding Martin Robinson to work more on WebKit MathML or contacting me directly to establish some kind of part-time consulting agreement.

Please leave a comment on this blog or send me a private mail, if you agree that funding MathML in browsers is important, if you like the crowd funding idea and plan to contribute ; or if you have any opinions about alternative funding options. Also, please tell me what seem to be the priority for you and your projects among what I have mentioned above (layout engines, features etc) or among others that I may have forgotten. Of course, any other constructive comment to help MathML support in browsers is welcome. I plan to submit features on catincan soon, once I have more feedback on what people are interested in. Thank you!

## September 06, 2013

### WebKit and C++11

#### Surfin’ Safari

I am happy to announce that as of r155146, we now require our various ports to build with compilers that support some C++11 features. This means that we don’t need to use the COMPILER_SUPPORTS() macro to conditionally use these features anymore. These are:

• Type inference
• Static assertions
• Move semantics

We’ve chosen these three features because they are well-supported in recent versions of the compilers we use: clang, MSVC and GCC.

What does this mean for people writing code? Here are three code examples where these three features come in handy:

Type inference

Type inference using the auto keyword will automatically deduce the type of a variable based on its initializer. This is especially useful iterators. This loop:

HashMap<OriginStack, OwnPtr<ExecutionCounter> >::const_iterator end = m_counters.end();
for (HashMap<OriginStack, OwnPtr<ExecutionCounter> >::const_iterator iter = m_counters.begin(); iter != end; ++iter) {
...
}

becomes

for (auto it = m_counters.begin(), end = m_counters.end(); it != end; ++it) {
...
}

Unfortunately, the new range-based for syntax is not supported by all compilers, but this is definitely a step in the right direction.

Static assertions

static_assert is a way to declare compile-time assertions. If an assertion is false, the compiler will produce an error. WTF already has a COMPILE_ASSERT macro that provides this functionality, but static_assert produces better error messages.

COMPILE_ASSERT(sizeof(AtomicString) == sizeof(String), atomic_string_and_string_must_be_same_size);

gives the error

/Source/WTF/wtf/text/AtomicString.cpp:43:1: error: 'dummyatomic_string_and_string_must_be_same_size' declared as an array with a negative size
COMPILE_ASSERT(sizeof(AtomicString) == sizeof(String), atomic_string_and_string_must_be_same_size);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /Source/WTF/wtf/text/AtomicString.cpp:23:
In file included from /Source/WTF/config.h:62:
In file included from /Source/WTF/wtf/FastMalloc.h:25:
In file included from /Source/WTF/wtf/PossiblyNull.h:29:
/Source/WTF/wtf/Assertions.h:324:60: note: expanded from macro 'COMPILE_ASSERT'
#define COMPILE_ASSERT(exp, name) typedef int dummy##name [(exp) ? 1 : -1]

Whereas

static_assert(sizeof(AtomicString) == sizeof(String), "AtomicString and String must have the same size");

gives

/Source/WTF/wtf/text/AtomicString.cpp:43:1: error: static_assert failed "AtomicString and String must have the same size"
static_assert(sizeof(AtomicString) == sizeof(String), "AtomicString and String must have the same size");
^             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Move semantics (rvalue references and move constructors)

Move semantics can provide improved performance when passing objects by value by moving the data instead of copying it. What it means for WebKit is that we can stop using out parameters in functions that return Vectors. For example:

void HTMLFormElement::getNamedElements(const AtomicString& name, Vector<RefPtr<Node> >& namedItems)
{
// http://www.whatwg.org/specs/web-apps/current-work/multipage/forms.html#dom-form-nameditem
elements()->namedItems(name, namedItems);

HTMLElement* elementFromPast = elementFromPastNamesMap(name);
if (namedItems.size() == 1 && namedItems.first() != elementFromPast)
else if (elementFromPast && namedItems.isEmpty())
namedItems.append(elementFromPast);
}

becomes

Vector<RefPtr<Node>> HTMLFormElement::namedElements(const AtomicString& name)
{
// http://www.whatwg.org/specs/web-apps/current-work/multipage/forms.html#dom-form-nameditem
Vector<RefPtr<Node>> namedItems = elements()->namedItems(name);

HTMLElement* elementFromPast = elementFromPastNamesMap(name);
if (namedItems.size() == 1 && namedItems.first() != elementFromPast)
else if (elementFromPast && namedItems.isEmpty())
namedItems.append(elementFromPast);

return namedItems;
}

(Note that this may have been true in the past in some cases too, due to the named return value optimization), but now it’s safe to do this for all Vectors with a zero inline capacity as well as HashMap and HashSet too!

Move semantics is an interesting topic that I hope to cover further in another blog post, so I’ll only mention it briefly here.

One more thing

Astute readers may have noticed another C++11 feature in the previous example that we can now use. With C++11 there is no need to use a space between right angle brackets when closing template arguments lists! This means that

OwnPtr<Vector<RefPtr<Node> > > m_childNodes;

becomes

OwnPtr<Vector<RefPtr<Node>>> m_childNodes;

Personally I’m really excited about using these features and I think they will be useful throughout the codebase. In time we’re going to start requiring even more C++11 features but this is a good start.

## August 27, 2013

### HTML Alchemy – Combining CSS Shapes with CSS Regions

I have been working on rendering for almost a year now. Since I landed the initial implementation of Shapes on Regions in both Blink and WebKit, I’m incredibly excited to talk a little bit about these features and how you can combine them together.

Don’t know what CSS Regions and Shapes are? Start here!

The first ingredient in my HTML alchemy kitchen is CSS Regions. With CSS Regions, you can flow content into multiple styled containers, which gives you enormous creative power to make magazine style layouts. The second ingredient is CSS Shapes, which gives you the ability to wrap content inside or outside any shape. In this post I’ll talk about the “shape-inside” CSS property, which allows us to wrap content inside an arbitrary shape.

Let’s grab a bowl and mix these two features together, CSS Regions and CSS Shapes to produce some really interesting layouts!

In the latest Chrome Canary and Safari WebKit Nightly, after enabling the required experimental features, you can flow content continuously through multiple kinds of shapes. This rocks! You can step out from the rectangular text flow world and break up text into multiple, non-rectangular shapes.

## Demo

If you already have the latest Chrome Canary/Safari WebKit Nightly, you can just go ahead and try a simple example on codepen.io. If you are too lazy, or if you want to extend your mouse button life by saving a few button clicks, you can continue reading.

In the picture above we see that the “Lorem ipsum” story flows through 4 different, colorful regions. There is a circle shape on each of the first two fixed size regions. Check out the code below to see how we apply the shape to the region. It’s pretty straightforward, right?
#region1, #region2 {
-webkit-flow-from: flow;
background-color: yellow;
width: 200px;
height: 200px;
-webkit-shape-inside: circle(50%, 50%, 50%);
}
The content flows into the third (percentage sized) region, which represents a heart (drawn by me, all rights reserved). I defined the heart’s coordinates in percentages, so the heart will stretch as you resize the window.
#region3 {
-webkit-flow-from: flow;
width: 50%;
height: 400px;
background-color: #EE99bb;
-webkit-shape-inside: polygon(11.17% 10.25%,2.50% 30.56%,3.92% 55.34%,12.33% 68.87%,26.67% 82.62%,49.33% 101.25%,73.50% 76.82%,85.17% 65.63%,91.63% 55.51%,97.10% 31.32%,85.79% 10.21%,72.47% 5.35%,55.53% 14.12%,48.58% 27.88%,41.79% 13.72%,27.50% 5.57%);
}

The content that doesn’t fit in the first three regions flows into the fourth region. The fourth region (see the retro-blue background color) has its CSS width and height set to auto, so it grows to fit the remaining content.

## Real world examples

After trying the demo and checking out the links above, I’m sure you’ll see the opportunities for using shape-inside with regions in your next design. If you have some thoughts on this topic, don’t hesitate to comment. Please keep in mind that these features are under development, and you might run into bugs. If you do, you should report them on WebKit’s Bugzilla for Safari or Chromium’s issue tracker for Chrome. Thanks for reading!

## August 06, 2013

### WebGL, at last!

#### Brent Fulgham

It's been a long time since I've written an update -- but my lack of blog posting is not an indication of a lack of progress in WebKit or the WinCairo port. Since I left my former employer (who *still* hasn't gotten around to updating the build machine I set up there), we've:

• Migrated from Visual Studio 2005 to Visual Studio 2010 (and soon, VS2012)
• Enabled New-run-webkit-tests
• Updated the WinCairo Support Libraries to support 64-bit builds
• Integrated a ton of cURL improvements and extensions thanks to the TideSDK guys
• and ...
... thanks to the hard work of Alex Christensen, brought up WebGL on the WinCairo port.  This is a little exciting for me, because it marks the first time (I can recall) where the WinCairo port actually gained a feature that was not already part of the core Apple Windows port.

The changes needed to see these circa-1992 graphics in all their three-dimensional glory are already landed in the WebKit tree.  You just need to:

1. Enable the libEGL, libGLESv2, translator_common, translator_glsl, and translator_hlsl for the WinCairo build (they are currently turned off).
2. Make the following change to WTF/wtf/FeatureDefines.h:

Brent Fulgham@WIN7-VM ~/WebKit/Source/WTF/wtf
svn diff Index: FeatureDefines.h =================================================================== --- FeatureDefines.h (revision 153733) +++ FeatureDefines.h (working copy) @@ -245,6 +245,13 @@ #define ENABLE_VIEW_MODE_CSS_MEDIA 0 #endif +#define ENABLE_WEBGL 1 +#define WTF_USE_3D_GRAPHICS 1 +#define WTF_USE_OPENGL 1 +#define WTF_USE_OPENGL_ES_2 1 +#define WTF_USE_EGL 1 +#define WTF_USE_GRAPHICS_SURFACE 1 + #endif /* PLATFORM(WIN_CAIRO) */ /* --------- EFL port (Unix) --------- */ Performance is a little ragged, but we hope to improve that in the near future. We have plenty of more plans for the future, including full 64-bit support (soon), and hopefully some improvements to the WinLauncher application to make it a little more useful. As always, if you would like to help out, ## July 10, 2013 ### Fuzzinator, a mutation and generation based browser fuzzer #### University of Szeged Fuzzers are widely used tools for testing software. They can generate random test cases and use them as input against the software under fuzzing/testing. Since the tests have randomly-built content, it is not necessary to check them for correctness, but they are suitable for catching rough bugs like use-after-frees, memory corruptions, assertion failures and further crashes. There are many approaches how to generate these tests, but all of them can be categorized into three main groups: whitebox, blackbox and graybox fuzzers. read more ## May 15, 2013 ### CSS Level 3 Text Decoration on WebKit and Blink – status #### Bruno de Oliveira Abinader It’s been a while since I wrote the last post about progress on implementing CSS Level 3 Text Decoration features in WebKit. I’ve been involved with other projects but now I can finally resume the work in cooperation with my colleague from basysKom, Lamarque Souza. So far we have implemented: • text-decoration-line (link) • text-decoration-style (link) • text-decoration-color (link) • text-underline-position (link) These properties are currently available under -webkit- prefix on WebKit, and guarded by a feature flag - CSS3_TEXT – which is enabled by default on both EFL and GTK ports. On Blink, plans are to get these properties unprefixed and under a runtime flag, which can be activated by enabling the “Experimental WebKit Features” (updated to “Experimental Web Platform Features” in latest builds) flag – see chrome://flags inside Google Chrome/Chromium). There are still some Skia-related issues to fix on Blink to enable proper dashed and dotted text decoration styles to be displayed. In the near future, we shall also have the text-decoration shorthand as specified on CSS Level 3 specification. See below a summary of things I plan to finish in the near future: • [webkit] Property text-decoration-line now accepts blink as valid value • [blink] Fix implementation of dashed and dotted styles on Skia • [blink] Fix an issue where previous Skia stroke styles were used when rendering paint decorations • [blink] Implement CSS3_TEXT as a runtime flag • [blink] Property text-decoration-line now accepts blink as valid value • [blink] Implement support for text-decoration shorthand • [webkit] Implement support for text-decoration shorthand Note: Please do not confuse text-decoration‘s blink value with Blink project Stay tuned for further updates! ## March 27, 2013 ### Freeing the Floats of the Future From the Tyranny of the Rectangle #### Adobe Web Platform With modern web layout you can have your content laid out in whatever shape you want as long as it’s a rectangle. Designers in other media have long been able to have text and other content lay out inside and around arbitrarily complex shapes. The CSS Exclusions, CSS Shapes Level 1, and CSS Shapes Level 2 specifications aim to bring this capability to the web. While these features aren’t widely available yet, implementation is progressing and it’s already possible to try out some of the features yourself. Internet Explorer 10 has an implementation of the exclusions processing model, so you can try out exclusions in IE 10 today. At Adobe we have been focusing on implementing the shapes specification. We began with an implementation of shape-inside and now have a working implementation of the shape-outside property on floats. We have been building our implementation in WebKit, so the easiest way to try it out yourself is to download a copy of Chrome Canary. Once you have Canary, enable Experimental Web Platform Features and go wild! ## What is shape-outside? “Now hold up there,” you may be thinking, “I don’t even know what a shape-outside is and you want me to read this crazy incomprehensible specification thing to know what it is!?!” Well you’ll be happy to know that it really isn’t that complex, especially in the case of floats. When an element is floated, inline content avoids the floated element. Content flows around the margin box of the element as defined by the CSS box model. The shape-outside CSS property allows you to tell the browser to use a specified shape instead of the margin box when wrapping content around the floating element. The current implementation allows for rectangles, rounded rectangles, circles, ellipses, and polygons. While this gives a lot of flexibility, eventually you will be able to use a SVG path or the alpha channel of an image to make it easier to create complex shapes. ## How do I use it? First, you need to get a copy of Chrome Canary and then enable Experimental Web Platform features. Once you have that, load up this post in Chrome Canary so that you can click on the images below to see a live example of the code. Even better, the examples are on Codepen, so you can and should play with them yourself and see what interesting things you can come up with. Note that in this post and the examples I use the unprefixed shape-outside property. If you want to test these examples outside of my Codepen then you will need to use the prefixed -webkit-shape-outside property or use (which is a built in option in Codepen). We’ll start with a HTML document with some content and a float. Currently shape-outside only works on floating elements, so those are the ones to concentrate on. For example: (click on the image to see the code) You can now add the shape-outside property to the style for your floats. .float { shape-outside: circle(50%, 50%, 50%); } A circle is much more interesting than a standard rectangle, don’t you think? This circle is centered in the middle of the float and has a radius that is half the width of the float. The effect on the layout is something like this: While percentages were used for this circle, you can use any CSS unit you like to specify the shape. All of the relative units are relative to the dimensions of element where the shape-outside is specified. ### Supported shapes Circles are cool and all, but I promised you other shapes, and I will deliver. There are four types of shapes that are supported by the current shape-outside implementation: rectangle, circle, ellipse, and polygon. #### rectangle You have the ability to specify a shape-outside that is a fairly standard rectangle: shape-outside: rectangle(x, y, width, height); The x and y parameters specify the coordinates of the top-left corner of the rectangle. This coordinate is in relation to the top-left corner of the floating element’s content box. Because of the way this interacts with the rules of float positioning, setting these to anything other than 0 causes an effect that is similar to relatively positioning the float’s content. (Explaining this is beyond the scope of this post.) The width and height parameters should be self-explanatory: they are the width and height of the resulting rectangle. Where things get interesting is with the six-argument form of rectangle: shape-outside: rectangle(x, y, width, height, rx, ry); The first four arguments are the same as explained above, but the last two specify corner radii in the horizontal (rx) and vertical (ry) directions. This not only allows the creation of rounded rectangles, you can create circles and ellipses as well. (Just like with [border-radius][border-radius].) If you’re reading this in Chrome Canary with exclusions turned on, play around with this demo and see what other things you can do with the rectangles. #### circle I already showed you a simple circle demo and you’ll be happy to know that’s pretty much all there is to know about circles: shape-outside: circle(cx, cy, radius); The cx and cy parameters specify the coordinates of the center of the circle. In most situations you’ll want to put them at the center of your box. Just like with rectangles moving this around can be useful, but it behaves similarly to relatively positioning the float’s content with respect to the shape. The radius parameter is the radius of the resulting circle. In case you’d like to see it again, here’s what a circle looks like: While it is possible to create circles with rounded rectangles as described above, having a dedicated circle shape is much more convenient. #### ellipse Sometimes, you need to squish your circles and that’s where the ellipse comes in handy. shape-outside: ellipse(cx, cy, rx, ry); Just like a circle, an ellipse has cx and cy to specify the coordinates of its center and you will likely want to have them at the center of your float. And just like all the previous shapes, changing these around will cause the float’s content to position relative to your shape. The rx and ry parameters will look familiar from the rounded rectangle case and they are exactly what you would expect: the horizontal and vertical radii of the ellipse. Ellipses can be used to create circles (rx = ry) and rounded rectangles can be used to create ellipses, but it’s best to use the shape that directly suits your purpose. It’s much easier to read and maintain that way. Here’s an example of using an ellipse shape: #### polygon Now here’s where things get really interesting. The polygon shape-outside allows you to specify an arbitrary polygonal shape for your float: shape-outside: polygon(x1 y1, x2 y2, ... , xn yn); The parameters of the polygon are the x and y coordinates of each vertex of the shape. You can have as many vertices as you would like. Here’s an example of a simple polygon: Feel free to play with this and see what happens if you create more interesting shapes! ### Putting content in the float The previous examples all had divs without any content just to make it easier to read and understand the code, but a big motivation for shape-outside is to wrap around other content. Interesting layouts often involve wrapping text around images as this final example shows: As usual, you should take a look and play with the code for this example of text wrapping around floated images. This is just the beginning of the possibilities, as you can put a shape outside on any floating element with any content you want inside. ## Next steps We are still hard at work on fixing bugs in the current implementation and implementing the rest of the features in the CSS Shapes Level 1 specification. We welcome your feedback on what is already implemented and also on the spec itself. If you are interested in becoming part of the process, you can raise issues with the current WebKit implementation by filing bugs in the WebKit bugzilla. If you have issues with the spec, those are best raised on the www-style mailing list. And of course, you can leave your feedback as comments on this post. I hope that you enjoy experimenting with shape-outside and the other features we are currently working on. ## March 25, 2013 ### Web 3.8: the peace dividends release #### Xan López I’m very happy about this release. Thanks to hard choices that we dared to make in the past we are now breaking new ground and giving GNOME some of the tools it needs to be the premier free software operating system. It’s been a long way since I spent an entire GUADEC porting good old epiphany to this newfangled thing called “WebKit”, and what a ride it has been. There’s a lot to talk about, so let’s get started. ## WebKit2 For the first time in this release, Web uses by default the all new multi-process architecture known as WebKit2. The advantages of such a design are well known by most, but here is a brief list of what this means for us: • Stability: we now run all the WebKit code in a different process (WebProcess) than the UI code (UIProcess). Most crashes, by far, happen inside WebKit, so this will make the application a lot more stable. When crashes happen, you’ll get a message explaining how to continue browsing, just a reload away. Note that for 3.8 we run all the web pages in the same WebProcess, just like Safari for OSX did in 5.1, but we plan to move to multiple WebProcesses in the near future. • Responsiveness: not only most crashes happen inside WebKit, but most of your CPU (and GPU!) time will generally also be spent there. By moving this processing away we allow the UI to be always ready to react to your input, so tab switching and scrolling are now super smooth. You’ll have to see it to believe it, but trust me when I say the improvement is enormous. • Plugins: in WebKit2 plugins run in their own process (PluginProcess). In general this makes the browser more robust against the frequent crashes and hiccups of some plugins, but for GNOME in particular it means something even better. Flash, as our more loyal users know well, has not worked natively in Web since we switched to GTK+3. The Adobe plugin is stuck in GTK+2, and since using both libraries at the same time in one process is forbidden we have been forced to rely on things like nspluginwrapper for a while. Well, not anymore: we compile our PluginProcess with GTK+2 precisely for this reason, so Flash works again out of the box. • Security: finally, by isolating all the web content from the application we reduce the possibility of malicious code having access to sensitive information. This will be greatly enhanced in the future with the sandboxing of the WebProcess, but 3.8 lays the first stone for a safer browsing. Our WebKit2 port and Web backend have been more or less in continuous development for more than 2 years. This is the result of a lot of hard work by all the WebKit contributors, the Igalia WebKit team and the Web developers. Despite being a collective effort, like most free software, I want to thank Carlos García Campos in particular for leading the WebKit2GTK+ effort with so much energy. His hard work and perseverance were instrumental in making this happen, so the usual beverages or thank you notes are more than deserved next time you see him. All this would be more than enough for a single release, but there is much more to see. Let’s keep going. ## Private browsing As advanced during the last WebKitGTK+ hackfest, Web 3.8 brings a straightforward way of launching a temporary and private browsing session, free from any data that could possibly identify you, that will leave no trace on the hard drive once you are done with it. Just go to the application menu and click “New Incognito Window”, you are all set. ## Undo close tab You closed a tab just to realize you actually needed to check one more thing in there. You pressed the wrong key. Selected the wrong menu item. Nevermind, in 3.8 Web will remember the tabs (and windows!) you have recently closed, and bringing them back to live is as easy as pressing Ctrl-Shift-T or selecting “Reopen Closed Tab” in the application menu. ## UI polish You want a shiny new search bar? We have it: A handy new tab button in the main toolbar? Got it: Vastly improved Web App icons and titles? Yep: Fancy HTML5 media controls perhaps? You bet: Plus less clutter in the gear menu, improved theming, simplified Preferences dialog, and many more small UI tweaks. ## 3.10 and beyond As usual we are already working on the next major release. For 3.10 and beyond you can look forward to: • Multiple WebProcesses. This is still under development, but at the very least we think we’ll be able to provide either the current “just one” model or the “one per tab” variant. Ideally also the “one per domain instance” that Chrome uses by default, but this one will be trickier. Stay tuned. • Deeper GNOME integration. Hooking into the new Shell search APIs or the Settings privacy controls is high in our TODO list. • Overview improvements. Animations? Access to recent history or recently closed tabs? We think GNOME 3.8 is the best GNOME yet, and Web 3.8 is the best Web yet. We hope you’ll enjoy both, we definitely enjoyed doing our part. ## February 24, 2013 ### Edge-distance anti-aliasing #### Martin Robinson (You might want to go straight to the demo) Some months ago, I noticed that the Chromium compositor, the code which powers Chromium’s accelerated compositing implementation (and also Aura!) was anti-aliasing layer edges. This was especially surprising to me since I knew for a fact that my hardware didn’t support multisample anti-aliasing yet. Some people from the Chromium graphics team, who are incredibly friendly and helpful, pointed me to a very clever bit of code they were using to do edge-distance anti-aliasing for composited layers. Aliasing can happen when you sample a signal that has details that cannot be captured by your sample frequency. In the case of graphics, it’s what happens when features of the image exist in an area smaller than a pixel. One important feature is the edge of a piece of geometry, such as the edge of a shape drawn onto the page. When you start rotating shapes and projecting them with 3D CSS transforms, geometry that before aligned to pixel boundaries can move to the spaces between pixel boundaries. For instance, let’s zoom into the edge of triangle that we are rendering. Maybe in this case it’s half of a rotated div. If we naively decided the color of every pixel based on whether any of the triangle covered it at all, we’d end up with a jagged edge. One thing we could do to make the edge smooth is to determine how much area of the pixel is covered by the triangle. We could adjust the transparency of the shape color (the alpha value) by that percentage when painting the pixel. This process is a type of anti-aliasing and the percentage that the triangle covers the pixel is called coverage. Think of all the complicated geometric calculations we’d have to do to figure out the ratio exactly. Since we have to make these calculations for every pixel up to 60 times per second (for smooth animations), our rendering would be pretty slow if we actually did them! Instead, it’d be nice if we could somehow estimate how much of the pixel is covered and do less work. One approach is to calculate the distance from the pixel to the edge of the shape. If the pixel is more than one pixel’s distance away from the edge, we know that we should not paint the triangle color at all. If the pixel is closer than one one pixel’s distance from the edge, we should paint the triangle color, but reduced by some transparency factor. Luckily, OpenGL can run a little program for every pixel 1 it paints. This program is called a fragment shader. We can write up this logic in the fragment shader and change the triangle color for every pixel. Perhaps some of those reading who have had experience with OpenGL may notice here that this isn’t going to work as I’ve described. OpenGL already does something like the naive approach I talked about first. Some pixels (the ones OpenGL decided should be painted with the triangle color), will be properly anti-aliased, but many pixels will not be painted at all. For instance, if the coverage of the pixel is only 20% and OpenGL decided not to paint it, we wouldn’t even have a chance to determine how far it was from the triangle edge, because the fragment shader wouldn’t run for those missing pixels. Let’s “trick” OpenGL into painting more pixels than it would otherwise. A simple way to do this is to just make the triangle a little bit bigger. In fact, we can expand all the edges by less than one pixel and OpenGL will paint all those missing pixels. Now we have smooth edges! I spent some time implementing this for the TextureMapper accelerated compositor (and thus WebKitGTK+), so it’s not just the Chromium compositor that has this feature any longer. For me it makes a huge difference in the quality of 3D CSS content. For the purposes of demonstration, I’ve also reimplemented it in WebGL, so if you have a modern browser you can see it in action. ## September 11, 2012 ### We are almost there: Web in 3.6.0 #### Xan López It’s that time of the year again where we have a look at what happened in the project in the last 6 months. In mere weeks it will be released with the shiny GNOME 3.6 (best.release.ever), but since release notes don’t write themselves here’s a sneak preview of all the new toys in Web-land. ## The overview has landed As Claudio already advanced the most noticeable difference in 3.6 is the first iteration of what we call “The Overview”. This is still an evolving design and implementation, but we felt that it was important to land a first version in time for this release that brought actual, solid improvements to the user experience. What the overview currently does is easy to explain: we have changed the blank start page for a grid that holds your most visited pages. Your favorite pages are now easier to access, especially on touch devices, and we have put valuable screen real estate to work! But what about if some unwanted visitor ends up there? Fear not, if you need to you can remove them from the grid by clicking on the ‘X’ icon on the top right corner of each snapshot. There’s more to come, but we feel this is already much better than it was, and fixes a long standing feature request for a better start page experience. ## WebKit2, beta It’s been a long time in the making, but the first bits of the WebKit2 support are already in the master branch. As we had anticipated for now it is available in beta form, which means we don’t build it by default and there’s still some functionality missing. That being said, it is really usable at this point, and doing the actual porting has helped us a lot in maturing the up and coming next generation of the WebKit framework. If you want to give it a shot, just build the browser with “–with-webkit2″, and you’ll notice: • Increased responsiveness (how amazing the scrolling is!) and stability. • Thanks to the OOP plugin support GTK 2.x plugins work out of the box again. That means Flash support without having to rely on nspluginwrapper. • Other things that are there, but invisible to users, like increased security or a new and improved API, built on top of all our experience with the classic WebKit. You can look forward to having a WebKit2 powered Web by default in GNOME 3.8, but for now you are more than welcome to give us feedback about this Beta version. ## Fullscreen mode, now with more full and more screen For a long time Web’s fullscreen mode was somewhat awkward. You’d still get a toolbar, so it wasn’t really fullscreen, plus it would have a strange button embedded in it telling you how to go back to the safety of the vanilla mode. Probably this was fine for the time, but with more and more HTML5 games or presentations done inside browsers, it was about time we had way of making your browser show you the full content and nothing but the content. So we just did that: ## Unit testing and code coverage This is not sexy, but I think it’s really important. For a long time our test coverage was really poor. And when I say really poor, I mean completely non-existent. Some time ago we started to add a few tests here and there, but starting in this cycle we have taken this a lot more seriously and our test coverage has grown by leaps and bounds. We have unit tests for most major classes, they are executed automatically during distcheck (so you won’t release if you broke something), and lately we have added support for the code coverage infrastructure that is now available in gnome-common (thanks Philip!). As I write these lines our coverage is around 40%, which is not great but is a massive improvement considering where we were 6 months ago. These tests have helped us to catch a bunch of bugs (some really obscure and older than some good wines), prevented lots of regressions, and helped us to do some hairy refactorings with the confidence that we wouldn’t break absolutely everything. lib/egg, you are an embarrassment I think these three things (having unit tests, running them automatically before release, measuring your progress with code coverage) are very important, so I’m writing another post that just focuses on how to do this for a typical GNOME project. ## Other bits and pieces As usual there are lots of additional features and bugfixes, too numerous to mention: automatic session recovery, tab-less mode, Do Not Track, using SoupTLD to make the URL completion smarter (so it can automatically figure out that google.com is a URL, but foo.bar is a string you want to search), and many more. ## Onwards GNOME 3.8 But the show must go on, and Igalians never sleep. We are already working towards the next major release: in 6 months we expect to graduate the WebKit2 version of Web out of Beta status (deprecating the classic WebKit version) and land the next iteration of the overview as major new features. But those are just the known knowns, the unknown unknowns is where it’s at. Until then, happy hacking. ## August 01, 2012 ### WebKit CSS3 text-decoration properties (preview) #### Bruno de Oliveira Abinader WebKit currently supports CSS Text Level 2.1 version of text-decoration property (link). This version treats only about the decoration line types (underline, overline, line-through and blink – the latter is not supported on WebKit). The draft version of CSS Text Level 3 upgrades text-decoration (link) property as a shorthand to 3 newly added properties, named text-decoration-line (link), text-decoration-style (link) and text-decoration-color (link), and also adds text-decoration-skip (link) property. Among other WebKit stuff I’ve been doing lately, this feature implementation is one of the most cool ones I’m enjoying implementing. I’ve grabbed the task of implementing all of these CSS3 text-decoration* properties on WebKit, and results are great so far! As you can see below, these are the new text decoration styles (solid, double, dotted, dashed and wavy – the latter still requires platform support) available: Text decoration style layout test results on Qt platform And also specific text decoration colors can be set: Text decoration color layout test results on Qt platform These features (with exception to text-decoration-skip property) are already implemented on Firefox, thus it gets easier to compare results with different web engines. It is important to notice since CSS3 specification is still in development, all these properties have a -webkit- prefix (ie. -webkit-text-decoration), so text-decoration still maintains CSS2.1 specification requirements. The patches are being reviewed and will soon land upstream, let’s hope it will be soon! ## July 07, 2012 ### Accelerated compositing update #### Martin Robinson I believe it's past time to break the silence here, so what follows is a short update on the progress we've made at Igalia toward 3D CSS transforms and hardware accelerated animation in WebKitGTK+ (otherwise known as accelerated compositing). I'm happy to say that both the initial WebKit1 and WebKit2 implementation of this work have finally landed, and you can try it out now in the latest unstable releases. Epiphany in Gnome 3.6 will include accelerated compositing (smooth animations and fast WebGL), a port to the brand new WebKit2GTK+ API (stability and security), and a new interface. It's quite pleasant to watch the progress of my own rounding error as each day it continues transforming into a modern browser. There were some interesting design choices to make when implementing accelerated compositing in WebKit2. Ports typically choose one of two possibilities for where to actually composite the content of page layers. The first and simplest path, taken by the GTK+ and Mac ports is to do all GPU composition in the WebProcess, which the same process that renders the layer content. This is by far the simplest and most straight-forward path, as WebKit does not have to send bitmap and layer data across the process boundary. The Qt and EFL ports have chosen to do composition in the UIProcess, which is the process that controls the user interface components surrounding the page content. From what I understand, this more complex design is an attempt to lower the latency of touch events and to decrease the number of OpenGL context switches. It's unclear now what the best approach is for browsers on embedded systems, but composition in the WebProcess works quite well for Epiphany at the moment. During this development cycle we'll continue to improve the implementation of accelerated compositing, but we hope to start looking at other rendering and interactivity improvements such as accelerated canvas, a tiled backing store, touch event handling and a threaded scrolling implementation. I'm most excited about accelerated canvas, because of the work we've been doing recently on Cairo GL. The GL backend of Cairo has been experimental for some time and isn't widely distributed, but recently there's been an attempt to increase its performance and to make it more suitable for embedded platforms. Once we integrate Cairo GL with our accelerated compositing architecture in WebKitGTk+, canvas content can be rasterized directly on the GPU instead of the CPU. For most systems accelerated canvas means better performance and lower power usage. Hopefully, I can land the patches to enable this as early as Gnome 3.6, but I'm still not sure when the OpenGL backend in Cairo will be officially supported. This means that, for the moment at least, you'll need to compile Cairo yourself to test accelerated canvas. ## May 25, 2012 ### Memory consumption: QtWebKit->compare(WebKit1, WebKit2, SystemMalloc, TCmalloc) #### University of Szeged Last year I got a Nokia N9 on Qt Developer Days, it's a great mobile phone, I really like it, but I haven't published any memory measurement results about it yet. In my last post I did WebKit memory profiling on it with Valgrind, but it was all about heap usage. I think a number of persons are interested in the overall memory usage such as peak memory usage, the sizes of the used libraries, etc. During QtWebKit's life-cycle we switch from one library to another, usually because of performance considerations. In the past we do not take too much attention to memory consumption-related topics while switching between libraries, although it would be very vital to keep eye on this area as well. read more ## March 10, 2012 ### WebKitGTK+ Debian packaging repository changes #### Gustavo Noronha For a while now the git repository used for packaging WebKitGTK+ has been broken. Broken as in nobody was able to clone it. In addition to that, the packaging workflow had been changing over time, from a track-upstream-git/patches applied one to a import-orig-only/patches-not-applied one. After spending some more time trying to unbreak the repository for the third time I decided it might be a good time for a clean up. I created a new repository, imported all upstream versions for series 1.2.x (which is in squeeze), 1.6.x (unstable), and 1.7.x (experimental). I also imported packaging-related commis for those versions using git format-patch and black magic. One of the good things about doing this move, and which should make hacking the WebKitGTK+ debian package more pleasant and accessible can be seen here: kov@goiaba ~/s/debian-webkit> du -sh webkit/.git webkit.old/.git 27M webkit/.git 1.6G webkit.old/.git If you care about the old repository, it’s on git.debian.org still, named old-webkit.git. Enjoy! ## October 09, 2011 ### Tests Active #### Brent Fulgham Looking back over this blog, I see that it was around a year ago that I got the initial WinCairo buildbot running. I'm very pleased to announce that I have gotten ahold of a much more powerful machine, and am now able to run a full build and tests in slightly under an hour -- a huge improvement over the old hardware which took over two hours just to build the software! This is a big step, because we can now track regressions and gauge correctness compared to the other platforms. Up to now, testing has largely consisted of periodic manual runs of the test suite, and a separate set of high-level tests run as part of a larger application. This was not ideal, because it was easy for low-level functions in WebKit that I rarely use to be broken and missed. All is not perfect, of course. Although over 12,000 tests now run (successfully) with each build, that is effectively two thirds of the full test suite. Most of the tests I have disabled are due to small differences in the output layout. I'm trying to understand why these differences exist, but I suspect many of them simply reflect small differences in Cairo compared to the CoreGraphics rendering layer. If any of you lurkers are interested in helping out, trying out some of the tests I have disabled and figuring out why they fail would be a huge help! ## June 14, 2011 ### Benchmarking Javascript engines for EFL #### Lucas De Marchi The Enlightenment Foundation Libraries has several bindings for other languages in order to ease the creation of end-user applications, speeding up its development. Among them, there’s a binding for Javascript using the Spidermonkey engine. The questions are: is it fast enough? Does it slowdown your application? Is Spidermonkey the best JS engine to be used? To answer these questions Gustavo Barbieri created some C, JS and Python benchmarks to compare the performance of EFL using each of these languages. The JS benchmarks were using Spidermonkey as the engine since elixir was already done for EFL. I then created new engines (with only the necessary functions) to also compare to other well-known JS engines: V8 from Google and JSC (or nitro) from WebKit. ## Libraries setup For all benchmarks EFL revision 58186 was used. Following the setup of each engine: • Spidermonkey: I’ve used version 1.8.1-rc1 with the already available bindings on EFL repository, elixir; • V8: version ﻿3.2.5.1, using a simple binding I created for EFL. I named this binding ev8; • JSC: ﻿WebKit’s sources are needed to compile JSC. I’ve used revision 83063. Compiling with CMake, I chose the EFL port and enabled the option SHARED_CORE in order to have a separated library for Javascript; ## Benchmarks Startup time: This benchmark measures the startup time by executing a simple application that imports evas, ecore, ecore-evas and edje, bring in some symbols and then iterates the main loop once before exiting. I measured the startup time for both hot and cold cache cases. In the former the application is executed several times in sequence and the latter includes a call to drop all caches so we have to load the library again from disk Runtime – Stress: This benchmark executes as many frames per second as possible of a render-intensive operation. The application is not so heavy, but it does some loops, math and interacts with EFL. Usually a common application would do far less operations every frame because many operations are done in EFL itself, in C, such as list scrolling that is done entirely in elm_genlist. This benchmark is made of 4 phases: • ﻿Phase 0 (P0): Un-scaled blend of the same image 16 times; • Phase 1 (P1): Same as P0, with additional 50% alpha; • Phase 2 (P2): Same as P0, with additional red coloring; • Phase 3 (P3): Same as P0, with additional 50% alpha and red coloring; The C and Elixir’s versions are available at EFL repository. Runtime – animation: usually an application doesn’t need “as many FPS as possible”, but instead it would like to limit to a certain amount of frames per second. E.g.: iphone’s browser tries to keep a constant of 60 FPS. This is the value I used on this benchmark. The same application as the previous benchmark is executed, but it tries to keep always the same frame-rate. ## Results The first computer I used to test these benchmarks on was my laptop. It’s a Dell Vostro 1320, Intel Core 2 Duo with 4 GB of RAM and a standard 5400 RPM disk. The results are below. Benchmarks on Dell 1320 laptop First thing to notice is there are no results for “Runtime – animation” benchmark. This is because all the engines kept a constant of 60fps and hence there were no interesting results to show. The first benchmark shows that V8′s startup time is the shortest one when considering we have to load the application and libraries from disk. JSC was the slowest and Spidermonkey was in between. With hot caches, however, we have another complete different scenario, with JSC being almost as fast as the native C application. Following, V8 with a delay a bit larger and Spidermonkey as the slowest one. The runtime-stress benchmark shows that all the engines are performing well when there’s some considerable load in the application, i.e. removing P0 from from this scenario. JSC was always at the same speed of native code; Spidermonkey and V8 had an impact only when considering P0 alone. Next computer to consider in order to execute these benchmarks was a Pandaboard, so we can see how well the engines are performing in an embedded platform. Pandaboard has an ARM Cortex-A9 processor with 1GB of RAM and the partition containing the benchmarks is in an external flash storage drive. Following the results for each benchmark: Benchmarks on Pandaboard Once again, runtime-animation is not shown since it had the same results for all engines. For the startup tests, now Spidermonkey was much faster than the others, followed by V8 and JSC in both hot and cold caches. In runtime-stress benchmark, all the engines performed well, as in the first computer, but now JSC was the clear winner. There are several points to be considered when choosing an engine to be use as a binding for a library such as EFL. The raw performance and startup time seems to be very near to the ones achieved with native code. Recently there were some discussions in EFL mailing list regarding which engine to choose, so I think it would be good to share these numbers above. It’s also important to notice that these bindings have a similar approach of elixir, mapping each function call in Javascript to the correspondent native function. I made this to be fair in the comparison among them, but depending on the use-case it’d be good to have a JS binding similar to what python’s did, embedding the function call in real python objects. ## April 29, 2011 ### Collection of WebKit ports #### Holger Freyther WebKit is a very successfull project. It is that in many ways. The code produced seems to very fast, the code is nice to work on, the people are great, the partys involved collaborate with each other in the interest of the project. The project is also very successfull in the mobile/smartphone space. All the major smartphone platforms but Windows7 are using WebKit. This all looks great, a big success but there is one thing that stands out. From all the smartphone platforms no one has fully upstreamed their port. There might be many reasons for that and I think the most commonly heard reason is the time needed to get it upstreamed. It is specially difficult in a field that is moving as fast as the mobile industry. And then again there is absolutely no legal obligation to work upstream. For most of today I collected the ports I am aware of, put them into one git repository, maybe find the point where they were branched, rebase their changes. The goal is to make it more easy to find interesting things and move them back to upstream. One can find the combined git tree with the tags here. I started with WebOS, moved to iOS, then to Bada and stopped at Android as I would have to pick the sourcecode for each android release for each phone from each vendor. I think I will just be happy with the Android git tree for now. At this point I would like to share some of my observations in the order I did the import. ## Palm Palm's release process is manual. In the last two releases they call the file .tgz but forgot to gzip it, in 2.0.0 the tarball name was in camel case. The thing that is very nice about Palm is that they provide their base and their changes (patch) separately. From looking at the 2.1.0 release it looks that for the Desktop version they want to implement Complex Font rendering. Earlier versions (maybe it is still the case) lack the support for animated GIF. ## iOS Apple's release process seems to be very structured. The source can be downloaded here. What I think is to note is that the release tarball contains some implementations of WebCore only as .o file and Apple has stopped releasing the WebKit sourcecode beginning with iOS 4.3.0. ## Bada This port is probably not known by many. The release process seems to be manual as well, the name of directories changed a lot between the releases, they come with a WML Script engine and they do ship something they should not ship. I really hope that this combined tree is useful for porters that want to see the tricks used in the various ports and don't want to spend the time looking for each port separately. ## February 13, 2011 ### How to make the GNU Smalltalk Interpreter slower #### Holger Freyther This is another post about a modern Linux based performance measurement utility. It is called perf, it is included in the Linux kernel sources and it entered the kernel in v2.6.31-rc1. In many ways it is obsoleting OProfile, in fact for many architectures oprofile is just a wrapper around the perf support in the kernel. perf comes with a few nice application. perf top provides a statistics about which symbols in user and in kernel space are called, perf record to record an application or to start an application to record it and then perf report to browse this report with a very simple CLI utility. There are tools to bundle the record and the application in an archive, a diff utility. For the last year I was playing a lot with GNU Smalltalk and someone posted the results of a very simplistic VM benchmark ran across many different Smalltalk implementations. In one of the benchmarks GNU Smalltalk is scoring last among the interpreters and I wanted to understand why it is slower. In many cases the JavaScriptCore interpreter is a lot like the GNU Smalltalk one, a simple direct-threaded bytecode interpreter, uses computed goto (even is compiled with -fno-gcse as indicated by the online help, not that it changed something for JSC), heavily inlined many functions. There are also some differences, the GNU Smalltalk implementation is a lot older and in C. The first notable is that it is a Stack Machine and not register based, there are global pointers for the SP and the IP. Some magic to make sure that in the hot loop the IP/SP is 'local' in a register, depending on the available registers also keep the current argument in one, the interpreter definition is in a special file format but mostly similar to how Interepreter::privateExecute is looking like. The global state mostly comes from the fact that it needs to support switching processes and there might be some event during the run that requires access to the IP to store it to resume the old process. But in general the implementation is already optimized and there is little low hanging fruits and most experiments result in a slow down. The two important things are again: Having a stable benchmark, having a tool to help to know where to look for things. In my case the important tools are perf stat, perf record, perf report and perf annotate. I have put a copy of the output to the end of this blog post. The stat utility provides one with number of instructions executed, branches, branch misses (e.g. badly predicted), L1/L2 cache hits and cache misses. The stable benchmark helps me to judge if a change is good, bad or neutral for performance within the margin of error of the test. E.g. if I attempt to reduce the code size the instructions executed should decrease, if I start putting __builtin_expect.. into my code the number of branch misses should go down as well. The other useful utility is to the perf report that allows one to browse the recorded data, this can help to identify the methods one wants to start to optimize, it allows to annotate these functions inside the simple TUI interface, but does not support searching in it. Because the codebase is already highly optimized any of my attempts should either decrease the code size (and the pressure on the i-cache), the data size (d-cache), remove stores or loads from memory (e.g. reorder instructions), fix branch predictions. The sad truth is that most of my changes were either slow downs or neutral to the performance and it is really important to undo these changes and not have false pride (unless it was also a code cleanup or such). So after about 14 hours of toying with it the speed ups I have managed to make come from inlining a method to unwind a context (callframe), reordering some compares on the GC path and disabling the __builtin_expect branch hints as they were mostly wrong (something the kernel people found to be true in 2010 as well). I will just try harder, or try to work on the optimizer or attempt something more radical... perf stat gst -f Bench.st
219037433 bytecodes/sec; 6025895 sends/sec

Performance counter stats for 'gst -f Bench.st':

2076 context-switches # 0.000 M/sec
123 CPU-migrations # 0.000 M/sec
3925 page-faults # 0.000 M/sec
22215005506 cycles # 1285.583 M/sec (scaled from 70.02%)
40593277297 instructions # 1.827 IPC (scaled from 80.00%)
5063469832 branches # 293.023 M/sec (scaled from 79.98%)
70691940 branch-misses # 1.396 % (scaled from 79.98%)
27844326 cache-references # 1.611 M/sec (scaled from 20.02%)
134229 cache-misses # 0.008 M/sec (scaled from 20.03%)

17.838888599 seconds time elapsed

PS: The perf support probably works best on Intel based platforms and the biggest other problem is that perf annotate has some issues when the code is included from other c files.

## October 23, 2010

### Easily embedding WebKit into your EFL application

#### Lucas De Marchi

This is the first of a series of posts that I’m planning to do using basic examples in EFL, the Enlightenment Foundation Libraries. You may have heard that EFL is reaching its 1.0 release. Instead of starting from the very beginning with the basic functions of these libraries, I decided to go the opposite way, showing the fun stuff that is possible to do. Since I’m also an WebKit developer, let’s put the best of both softwares together and have a basic window rendering a webpage.

Before starting off, just some remarks:

1. I’m using here the basic EFL + WebKit-EFL (sometimes called ewebkit). Developing an EFL application can be much simpler, particularly if you use an additional library with pre-made widgets like Elementary. However, it’s good to know how the underlying stuff works, so I’m providing this example.
2. This could have been the last post in a series when talking about EFL since it uses at least 3 libraries. Don’t be afraid if you don’t understand what a certain function is for or if you can’t get all EFL and WebKit running right now. Use the comment section below and I’ll make my best to help you.

### Getting EFL and WebKit

In order to able to compile the example here, you will need to compile two libraries from source: EFL and WebKit. For both libraries, you can either get the last version from svn or use the last snapshots provided.

• EFL:

Grab a snapshot from the download page. How to checkout the latest version from svn is detailed here, as well as some instructions on how to compile

• WebKit-EFL:

A very detailed explanation on how to get WebKit-EFL up and running is available on trac. Recently, though, WebKit-EFL started to be released too. It’s not detailed in the wiki yet, but you can grab a snapshot instead of checking out from svn.

### hellobrowser!

In the spirit of “hello world” examples, our goal here is to make a window showing a webpage rendered by WebKit. For the sake of simplicity, we will use a default start page and put a WebKit-EFL “widget” to cover the entire window. See below a screenshot:

hellobrowser - WebKit + EFL

The code for this example is available here. Pay attention to a comment in the beginning of this file that explains how to compile it:

 gcc -o hellobrowser hellobrowser.c \ -DEWK_DATADIR="\"$(pkg-config --variable=datadir ewebkit)\"" \$(pkg-config --cflags --libs ecore ecore-evas evas ewebkit)

The things worth noting here are the dependencies and a variable. We directly depend on ecore and evas from EFL and on WebKit. We define a variable, EWK_DATADIR, using pkg-config so our browser can use the default theme for web widgets defined in WebKit. Ecore handles events like mouse and keyboard inputs, timers etc whilst evas is the library responsible for drawing. In a later post I’ll detail them a bit more. For now, you can read more about them on their official site.

The main function is really simple. Let’s divide it by pieces:

 // Init all EFL stuff we use evas_init(); ecore_init(); ecore_evas_init(); ewk_init();

Before you use a library from EFL, remember to initialize it. All of them use their own namespace, so it’s easy to know which library you have to initialize: for example, if you call a function starting by “ecore_”, you know you first have to call “ecore_init()”. The last initialization function is WebKit’s, which uses the “ewk_” namespace.

 window = ecore_evas_new(NULL, 0, 0, 800, 600, NULL); if (!window) { fprintf(stderr, "something went wrong... :(\n"); return 1; }

Ecore-evas then is used to create a new window with size 800×600. The other options are not relevant for an introduction to the libraries and you can find its complete documentation here.

 // Get the canvas off just-created window evas = ecore_evas_get(window);

From the Ecore_Evas object we just created, we grab a pointer to the evas, which is the space in which we can draw, adding Evas_Objects. Basically an Evas_Object is an object that you draw somewhere, i.e. in the evas. We want to add only one object to our window, that is where WebKit you render the webpages. Then, we have to ask WebKit to create this object:

 // Add a View object into this canvas. A View object is where WebKit will // render stuff. browser = ewk_view_single_add(evas);

Below I demonstrate a few Evas’ functions that you use to manipulate any Evas_Object. Here we are manipulating the just create WebKit object, moving to the desired position, resizing to 780x580px and then telling Evas to show this object. Finally, we tell Evas to show the window we created too. This way we have a window with an WebKit object inside with a little border.

 // Make a 10px border, resize and show evas_object_move(browser, 10, 10); evas_object_resize(browser, 780, 580); evas_object_show(browser); ecore_evas_show(window);

We need to setup a bit more things before having a working application. The first one is to give focus to the Evas_Object we are interested on in order to receive keyboard events when opened. Then we connect a function that will be called when the window is closed, so we can properly exit our application.

 // Focus it so it will receive pressed keys evas_object_focus_set(browser, 1);   // Add a callback so clicks on "X" on top of window will call // main_signal_exit() function ecore_event_handler_add(ECORE_EVENT_SIGNAL_EXIT, main_signal_exit, window);

After this, we are ready to show our application, so we start the mainloop. This function will only return when the application is closed:

 ecore_main_loop_begin();

The function called when the application is close, just tell Ecore to exit the mainloop, so the function above returns and the application can shutdown. See its implementation below:

 static Eina_Bool main_signal_exit(void *data, int ev_type, void *ev) { ecore_evas_free(data); ecore_main_loop_quit(); return EINA_TRUE; }

Before the application exits, we shutdown all the libraries that were initialized, in the opposite order:

 // Destroy all the stuff we have used ewk_shutdown(); ecore_evas_shutdown(); ecore_shutdown(); evas_shutdown();

This is a basic working browser, with which you can navigate through pages, but you don’t have an entry to set the current URL, nor “go back” and “go forward” buttons etc. All you have to do is start adding more Evas_Objects to your Evas and connect them to the object we just created. For a still basic example, but with more stuff implemented, refer to the EWebLauncher that we ship with the WebKit source code. You can see it in the “WebKitTools/EWebLauncher/” folder or online at webkit’s trac. Eve is another browser with a lot more features that uses Elementary in addition to EFL, WebKit. See a blog post about it with some nice pictures.

Now, let’s do something funny with our browser. With a bit more lines of code you can turn your browser upside down. Not really useful, but it’s funny. All you have to do is to rotate the Evas_Object WebKit is rendering on. This is implemented by the following function:

 // Rotate an evas object by 180 degrees static void _rotate_obj(Evas_Object *obj) { Evas_Map *map = evas_map_new(4);   evas_map_util_points_populate_from_object(map, obj); evas_map_util_rotate(map, 180.0, 400, 300); evas_map_alpha_set(map, 0); evas_map_smooth_set(map, 1); evas_object_map_set(obj, map); evas_object_map_enable_set(obj, 1);   evas_map_free(map); }

See this screenshot below and  get the complete source code.

EFL + WebKit doing Politreco upside down

## September 06, 2008

### Skia graphics library in Chrome: First impressions

#### Alp Toker

With the release of the WebKit-based Chrome browser, Google also introduced a handful of new backends for the browser engine including a new HTTP stack and the Skia graphics library. Google’s Android WebKit code drops have previously featured Skia for rendering, though this is the first time the sources have been made freely available. The code is apparently derived from Google’s 2005 acquisition of North Carolina-based software firm Skia and is now provided under the Open Source Apache License 2.0.

Weighing in at some 80,000 lines of code (to Cairo’s 90,000 as a ballpark reference) and written in C++, some of the differentiating features include:

• Optimised software-based rasteriser (module sgl/)
• Optional GL-based acceleration of certain graphics operations including shader support and textures (module gl/)
• Animation capabilities (module animator/)
• Some built-in SVG support (module (svg/)
• Built-in image decoders: PNG, JPEG, GIF, BMP, WBMP, ICO (modules images/)
• Text capabilities (no built-in support for complex scripts)
• Some awareness of higher-level UI toolkit constructs (platform windows, platform events): Mac, Unix (sic. X11, incomplete), Windows, wxwidgets
• Performace features
• Copy-on-write for images and certain other data types
• Extensive use of the stack, both internally and for API consumers to avoid needless allocations and memory fragmentation

The library is portable and has (optional) platform-specific backends:

• Fonts: Android / Ascender, FreeType, Windows (GDI)
• XML: expat, tinyxml
• Android shared memory (ashmem) for inter-process image data references

### Skia Hello World

In this simple example we draw a few rectangles to a memory-based image buffer. This also demonstrates how one might integrate with the platform graphics system to get something on screen, though in this case we’re using Cairo to save the resulting image to disk:

 #include "SkBitmap.h" #include "SkDevice.h" #include "SkPaint.h" #include "SkRect.h" #include   int main() { SkBitmap bitmap; bitmap.setConfig(SkBitmap::kARGB_8888_Config, 100, 100); bitmap.allocPixels(); SkDevice device(bitmap); SkCanvas canvas(&device); SkPaint paint; SkRect r;   paint.setARGB(255, 255, 255, 255); r.set(10, 10, 20, 20); canvas.drawRect(r, paint);   paint.setARGB(255, 255, 0, 0); r.offset(5, 5); canvas.drawRect(r, paint);   paint.setARGB(255, 0, 0, 255); r.offset(5, 5); canvas.drawRect(r, paint);   { SkAutoLockPixels image_lock(bitmap); cairo_surface_t* surface = cairo_image_surface_create_for_data( (unsigned char*)bitmap.getPixels(), CAIRO_FORMAT_ARGB32, bitmap.width(), bitmap.height(), bitmap.rowBytes()); cairo_surface_write_to_png(surface, "snapshot.png"); cairo_surface_destroy(surface); }   return 0; }

You can build this example for yourself linking statically to the libskia.a object file generated during the Chrome build process on Linux.

### Not just for Google Chrome

The Skia backend in WebKit, the first parts of which are already hitting SVN (r35852, r36074) isn’t limited to use in the Chrome/Windows configuration and some work has already been done to get it up and running on Linux/GTK+ as part of the ongoing porting effort.

The post Skia graphics library in Chrome: First impressions appeared first on Alp Toker.

## June 12, 2008

### WebKit Meta: A new standard for in-game web content

#### Alp Toker

Over the last few months, our browser team at Nuanti Ltd. has been developing Meta, a brand new WebKit port suited to embedding in OpenGL and 3D applications. The work is being driven by Linden Lab, who are eagerly investigating WebKit for use in Second Life.

While producing Meta we’ve paid great attention to resolving the technical and practical limitations encountered with other web content engines.

uBrowser running with the WebKit Meta engine

### High performance, low resource usage

Meta is built around WebKit, the same engine used in web browsers like Safari and Epiphany, and features some of the fastest content rendering around as well as nippy JavaScript execution with the state of the art SquirrelFish VM. The JavaScript SDK is available independently of the web renderer for sandboxed client-side game scripting and automation.

It’s also highly scalable. Some applications may need only a single browser context but virtual worlds often need to support hundreds of web views or more, each with active content. To optimize for this use case, we’ve cut down resource usage to an absolute minimum and tuned performance across the board.

### Stable, easy to use cross-platform SDK

Meta features a single, rock-solid API that works identically on all supported platforms including Windows, OS X and Linux. The SDK is tailored specifically to embedding and allows tight integration (shared main loop or operation in a separate rendering thread, for example) and hooks to permit seamless visual integration and extension. There is no global setup or initialization and the number of views can be adjusted dynamically to meet resource constraints.

### Minimal dependencies

Meta doesn’t need to use a conventional UI toolkit and doesn’t need any access to the underlying windowing system or the user’s filesystem to do its job, so we’ve done away with these concepts almost entirely. It adds only a few megabytes to the overall redistributable application’s installed footprint and won’t interfere with any pre-installed web browsers on the user’s machine.

### Nuanti will be offering commercial and community support and is anticipating involvement from the gaming industry and homebrew programmers.

In the mid term, we aim to submit components of Meta to the WebKit Open Source project, where our developers are already actively involved in maintaining various subsystems.

### Find out more

Today we’re launching meta.nuanti.com and two mailing lists to get developers talking. We’re looking to make this site a focal point for embedders, choc-full of technical details, code samples and other resources.

The post WebKit Meta: A new standard for in-game web content appeared first on Alp Toker.