Category: Igalia

Igalia related news

3 events in a month

As part of my job at Igalia, I have been attending 2-3 events per year. My role mostly as a Chromium stack engineer is not usually much demanding regarding conference trips, but they are quite important as an opportunity to meet collaborators and project mates.

This month has been a bit different, as I ended up visiting Santa Clara LG Silicon Valley Lab in California, Igalia headquarters in A Coruña, and Dresden. It was mostly because I got involved in the discussions for the web runtime implementation being developed by Igalia for AGL.

AGL f2f at LGSVL

It is always great to visit LG Silicon Valley Lab (Santa Clara, US), where my team is located. I have been participating for 6 years in the development of the webOS web stack you can most prominently enjoy in LG webOS smart TV.

One of the goals for next months at AGL is providing an efficient web runtime. In LGSVL we have been developing and maintaining WAM, the webOS web runtime. And as it was released with an open source license in webOS Open Source Edition, it looked like a great match for AGL. So my team did a proof of concept in May and it was succesful. At the same time Igalia has been working on porting Chromium browser to AGL. So, after some discussions AGL approved sponsoring my company, Igalia for porting the LG webOS web runtime to AGL.

As LGSVL was hosting the september 2018 AGL f2f meeting, Igalia sponsored my trip to the event.

AGL f2f Santa Clara 2018, AGL wiki CC BY 4.0

So we took the opportunity to continue discussions and progress in the development of the WAM AGL port. And, as we expected, it was quite beneficial to unblock tasks like AGL app framework security integration, and the support of AGL latest official release, Funky Flounder. Julie Kim from Igalia attended the event too, and presented an update on the progress of the Ozone Wayland port.

The organization and the venue were great. Thanks to LGSVL!

Web Engines Hackfest 2018 at Igalia

Next trip was definitely closer. Just 90 minutes drive to our Igalia headquarters in A Coruña.


Igalia has been organizing this event since 2009. It is a cross-web-engine event, where engineers of Mozilla, Chromium and WebKit have been meeting yearly to do some hacking, and discuss the future of the web.

This time my main interest was participating in the discussions about the effort by Igalia and Google to support Wayland natively in Chromium. I was pleased to know around 90% of the work had already landed in upstream Chromium. Great news as it will smooth integration of Chromium for embedders using Ozone Wayland, like webOS. It was also great to know the work for improving GPU performance reducing the number of copies required for painting web contents.

Web Engines Hackfest 2018 CC BY-SA 2.0

Other topics of my interest:
– We did a follow-up of the discussion in last BlinkOn about the barriers for Chromium embedders, sharing the experiences maintaining a downstream Chromium tree.
– Joined the discussions about the future of WebKitGTK. In particular the graphics pipeline adaptation to the upcoming GTK+ 4.

As usual, the organization was great. We had 70 people in the event, and it was awesome to see all the activity in the office, and so many talented engineers in the same place. Thanks Igalia!

Web Engines Hackfest 2018 CC BY-SA 2.0

AGL All Members Meeting Europe 2018 at Dresden

The last event in barely a month was my first visit to the beautiful town of Dresden (Germany).

The goal was continuing the discussions for the projects Igalia is developing for AGL platform: Chromium upstream native Wayland support, and the WAM web runtime port. We also had a booth showcasing that work, but also our lightweight WebKit port WPE that was, as usual, attracting interest with its 60fps video playback performance in a Raspberry Pi 2.

I co-presented with Steve Lemke a talk about the automotive activities at LGSVL, taking the opportunity to update on the status of the WAM web runtime work for AGL (slides here). The project is progressing and Igalia should be landing soon the first results of the work.

Igalia booth at AGL AMM Europe 2018

It was great to meet all this people, and discuss in person the architecture proposal for the web runtime, unblocking several tasks and offering more detailed planning for next months.

Dresden was great, and I can’t help highlighting the reception and guided tour in the Dresden Transportation Museum. Great choice by the organization. Thanks to Linux Foundation and the AGL project community!

Next: Chrome Dev Summit 2018

So… what’s next? I will be visiting San Francisco in November for Chrome Dev Summit.

I can only thank Igalia for sponsoring my attendance to these events. They are quite important for keeping things moving forward. But also, it is also really nice to meet friends and collaborators. Thanks Igalia!

Updated Chromium Legacy Wayland Support

Introduction

Future Ozone Wayland backend is still not ready for shipping. So we are announcing the release of an updated Ozone Wayland backend for Chromium, based on the implementation provided by Intel. It is rebased on top of latest stable Chromium release and you can find it in my team Github. Hope you will appreciate it.

Official Chromium on Linux desktop nowadays

Linux desktop is progressively migrating to use Wayland as the display server. It is the default option in Fedora, Ubuntu ~~and, more importantly, the next Ubuntu Long Term Support release will ship Gnome Shell Wayland display server by default~~ (P.S. since this post was originally written, Ubuntu has delayed the Wayland adoption for LTS).

As is, now, Chromium browser for Linux desktop support is based on X11. This means it will natively interact with an X server and with its XDG extensions for displaying the contents and receiving user events. But, as said, next generation of Linux desktop will be using Wayland display servers instead of X11. How is it working? Using XWayland server, a full X11 server built on top of Wayland protocol. Ok, but that has an impact on performance. Chromium needs to communicate and paint to X11 provided buffers, and then, those buffers need to be shared with Wayland display server. And the user events will need to be proxied from the Wayland display server through the XWayland server and X11 protocol. It requires more resources: more memory, CPU, and GPU. And it adds more latency to the communication.

Ozone

Chromium supports officially several platforms (Windows, Android, Linux desktop, iOS). But it provides abstractions for porting it to other platforms.

The set of abstractions is named Ozone (more info here). It allows to implement one or more platform components with the hooks for properly integrating with a platform that is in the set of officially supported targets. Among other things it provides abstractions for:
* Obtaining accelerated surfaces.
* Creating and obtaining windows to paint the contents.
* Interacting with the desktop cursor.
* Receiving user events.
* Interacting with the window manager.

Chromium and Wayland (2014-2016)

Even if Wayland was not used on Linux desktop, a bunch of embedded devices have been using Wayland for their display server for quite some time. LG has been shipping a full Wayland experience on the webOS TV products.

In the last 4 years, Intel has been providing an implementation of Ozone abstractions for Wayland. It was an amazing work that allowed running Chromium browser on top of a Wayland compositor. This backend has been the de facto standard for running Chromium browser on all these Wayland-enabled embedded devices.

But the development of this implementation has mostly stopped around Chromium 49 (though rebases on top of Chromium 51 and 53 have been provided).

Chromium and Wayland (2018+)

Since the end of 2016, Igalia has been involved on several initiatives to allow Chromium to run natively in Wayland. Even if this work is based on the original Ozone Wayland backend by Intel, it is mostly a rewrite and adaptation to the future graphics architecture in Chromium (Viz and Mus).

This is being developed in the Igalia GitHub, downstream, though it is expected to be landed upstream progressively. Hopefully, at some point in 2018, this new backend will be fully ready for shipping products with it. But we are still not there. ~~Some major missing parts are Wayland TextInput protocol and content shell support~~ (P.S. since this was written, both TextInput and content shell support are working now!).

More information on these posts from the authors:
* June 2016: Understanding Chromium’s runtime ozone platform selection (by Antonio Gomes).
* October 2016: Analysis of Ozone Wayland (by Frédéric Wang).
* November 2016: Chromium, ozone, wayland and beyond (by Antonio Gomes).
* December 2016: Chromium on R-Car M3 & AGL/Wayland (by Frédéric Wang).
* February 2017: Mus Window System (by Frédéric Wang).
* May 2017: Chromium Mus/Ozone update (H1/2017): wayland, x11 (by Antonio Gomes).
* June 2017: Running Chromium m60 on R-Car M3 board & AGL/Wayland (by Maksim Sisov).

Releasing legacy Ozone Wayland backend (2017-2018)

Ok, so new Wayland backend is still not ready in some cases, and the old one is unmaintained. For that reason, LG is announcing the release of an updated legacy Ozone Wayland backend. It is essentially the original Intel backend, but ported to current Chromium stable.

Why? Because we want to provide a migration path to the future Ozone Wayland backend. And because we want to share this effort with other developers, willing to run Chromium in Wayland immediately, or that are still using the old backend and cannot immediately migrate to the new one.

WARNING If you are starting development for a product that is going to happen in 1-2 years… Very likely your best option is already migrating now to the new Ozone Wayland backend (and help with the missing bits). We will stop maintaining it ourselves once new Ozone Wayland backend lands upstream and covers all our needs.

What does this port include?
* Rebased on top of Chromium m60, m61, m62 and m63.
* Ported to GN.
* It already includes some changes to adapt to the new Ozone Wayland refactors.

It is hosted at https://github.com/lgsvl/chromium-src.

Enjoy it!

Originally published at webOS Open Source Edition Blog. and licensed under Creative Commons Attribution 4.0.

WebKitGTK+ accelerated composition on Wayland

As part of my work at Igalia browsers team, I am working on making WebKitGTK+ and Epiphany work on Wayland.

Just running non 3D websites on Wayland did not involve too much work. But running the OpenGL accelerated code in WebKit was a bit more complicated. Though, I’ve got a first working version.

Video: Epiphany on Wayland running WebGL and CSS-3D

On WebKitGTK+, we enable the use of hardware acceleration with OpenGL for:

  • WebGL: web pages with a canvas using WebGL are run using the 3D hardware available.
  • Accelerated composition of layers. With stuff like CSS-3D transformations, 3D hardware acceleration is handy to composite the layers of a webpage.
You can read more about accelerated compositing on these posts from Martin Robinson: WebKitGTK+ hackfest wrapup, and Accelerated compositing update.

On X11, we use XComposite, sharing a Window among the GTK+ widget (WebKitWebView) and the GL contexts for WebGL and accelerated composition. We have a tree of layers, each one rendering to a texture. Then these textures are composited rendering directly to the X11 window.

On Wayland, things are a bit different. Wayland protocol does not define a way to share a buffer among clients, nor a way to “insert” a window inside another window. My solution is just making the accelerated compositor render the layers to another texture. When the time comes for the WebKitWebView to be drawn (using Cairo), we render this texture too. If we build GTK+ for using EGL, then this process happens completely on GPU.

Next step will be adding support for accelerated composition in WebKit2GTK+. The main challenge here is that the WebKitWebView widget is on UI process and the WebGL contexts and layers rendering are in Web Process. So, if we want to avoid buffers going to/from GPU, we need to share them between the two processes. DRM authentication through EGL_mesa_drm extension could help here.

IwkMail, mixing WebKit Gtk+, Camel and JQuery Mobile

In the last few weeks, as part of my work here at Igalia, I’ve been playing a bit with the concept of hybrid applications. In this case, I’ve created a basic prototype of a mail application, with its user interface completely written using JQuery Mobile, and with backend code in C and GObject. The result is iwkmail.

Screencast of iwkmail in action

Though it’s a simple experiment, I’ve added some mail basic functionality, so I could try to catch as much as possible of real requirements for how  we could improve the developers WebKit+GNOME experience creating hybrid applications.

My first conclusion is that it’s surprisingly easy and fast to develop such applications. Second, I could reuse tons of source code and modules from my old projects. This approach surely provides a way to create cool GNOME applications, using the most fashionable web client technologies.

So, you’ll get:

  • Browsing messages
  • Read/unread flags
  • Deleting messages
  • Creating and deleting mail accounts.
  • Storage protocols supported: IMAP and POP.
  • For sending mails, we support SMTP. There’s support for an outbox holding the messages to be sent.
  • A plain text composer, allowing to add attachments.

The UI is completely written in Javascript + HTML, using JQuery Mobile.

The backend side is done using Camel library inside Evolution Data Server, so we rely on a library well tested for more than 10 years.  All the code related to this is implemented in C+GObject, and I reused a good set of code from Modest, the default mail client for Nokia N810 and N900. I’ve got involved on its development for 3 years, so that’s a bunch of code I know well enough.

For communication, I use the AJAX-like JSONP protocol, and custom SoupRequest URI scheme handlers. Basically I expose some methods as iwk:addAcccount, iwk:getMessage, etc, and arguments are passed as usual in a web request. The result I obtain from this calls is a JSON object with the results of the call. Simple, and works very well.

I’ve pushed the work on github: https://github.com/jdapena/iwkmail. Feel free to try it!

Oh, I guess it’s very obvious that I did not spend too much time thinking on the project name… So, anyone proposing something that matches the IM acronym (I don’t want to rewrite the class names!) would deserve a beer.

Last, lots of thanks to Igalia for giving me the opportunity to do this experiment. As usual, fun stuff to work with.

Epiphany meets the web app stores

In last weeks, I’ve been taking a look at the web applications standards support in Epiphany, as part of my work at Igalia. Xan wrote about the Save as web application feature present in Epiphany 3.2, that is a base for very simple (and userful) web applications support in Gnome desktop.

To continue with this work, I’ve been investigating on adding support for some web app stores. So I’ve done an experimental implementation for Mozilla Open Web Apps (as in 2011 tech preview), Chrome Web Store hosted and packaged apps, and Chrome CRX-less apps.


Screencast using Chrome Web Store.

This is an experiment. Not supported, and it may actually stay out of official Epiphany. So there are lots of things not working at all. This is first a way to have a big number of apps to play with our application mode, and improve it. So no permissions check, URL’s match may be broken, many apps will fail to even log in… Did I say it is an experiment? Most obvious issues are related with this external links handling bug.

But, if you just want to play with it, just try my branch webapp in my Epiphany Github repository. By default, support is disabled, so you’ll have to enable these keys:

$ gsettings set org.gnome.Epiphany.web enable-chrome-apps true
$ gsettings set org.gnome.Epiphany.web enable-open-web-apps true

You can try with Mozilla Labs Apps Dir from 2011 tech preview and Chrome Web Store.

Talk about Modest 4 for Guadec next Thursday. Challenges of portability between Hildon and GNOME.

Tomorrow I’m leaving to GUADEC 2010.  I’m goint to assist only on Thursday this time, when I’ll be doing this year GUADEC talk about Modest project.

This time the talk focus will be completely different, as I’ll be explaining the process towards Modest 4, where we’re focusing in intensive refactoring, with the goal of releasing a product quality in GNOME, Moblin and Hildon/Maemo5 platforms.

Also, I’ll talk about some differences between Maemo and GNOME platforms, and some bits I miss in GNOME platform:

  • IP hearbeat (data transferences done in bursts to save energy).
  • libosso-abook (evolution data server addressbook and telepathy integration).
  • libalarm/alarmd (events scheduler integrated with dbus, and with support for waking up device).
  • … etc, etc.

I won’t ellaborate too much, but I’m trying to point some weak points in GNOME platform we could improve (just taking free software Maemo components, or improving GNOME platform components).

The talk will be on Thursday, at 14:45 in Seville room.

Clutter Grilo Player 0.1.1

This week I’ve been working a bit more in the Clutter Grilo Player. And finally did release 0.1.1:

  • Fullscreen button.
  • Keyboard shortcuts.
  • Volume control.
  • Now we sort search results.
  • Translation support.
  • Style fixes (no more ugly red buttons in media library).
  • Speedup in YouTube access.

Thanks to Chris Lord for his patches in clutter code, and Iago Toral for his help improving YouTube speed.

As usual, I uploaded the packages to CGP Launchpad PPA. The code, in CGP  gitorious.

First release of Clutter Grilo Player

Last weeks I’ve been playing with Clutter and Mx libraries, with the idea of knowing them deeper while also trying to help a bit. Honestly, I believe that the best way to learn about such things is just creating something using them.

So, knowing the fantastic effort done by Grilo team at Igalia, to create a framework for accessing different multimedia sources across the internet, I came to the idea of creating a very simple media player that uses MX widgets, Gstreamer, and Grilo framework.

And here it is, the first release of Clutter Grilo Player. It’s still dirty, but the general idea of the interface is there. It supports browsing and searching some Grilo providers, including Youtube and others.

Some links:

Tinymail moved to gitorious.

After some migration work, now we have Tinymail repository completely migrated to gitorious.org:

http://gitorious.org/tinymail

I’ve rescued all the branches available in our svn and tried to keep the proper authorship attributions.

So, from now on, the development should happen in gitorious, and, if you want to keep updated with the latest changes, this is the source to get the information.

I’ve also updated as much as possible the tinymail wiki with proper references to the gitorious.

I know I’ve just announced moving modest to gitorious, but modest was already in git. This time the change in tinymail is bigger as we’re also moving to git from svn! Big change, bigger benefits.