Okay, everyone. Welcome. We're going to start this talk two minutes early because Mario
is going to need some more time to talk about WebKit. Right. Mario, over to you.
Thank you. Hello. Thanks for coming here. The purpose of this talk is not to go very deep
into technicalities, but basically keep a kind of an overview of where we are in the context
of WebKit and Linux. My name is Mario. I'm suffering in the near. I've been working in
the Alia for quite a while. I'm also a partner of the company. I've been working mostly
on open social my life around genomes. I did a lot of working WebKit and Chromium and WebKit
again. And I also, this is also because I like it. I work a lot on Linux based operating systems
mainly, if you remember the Nokia times on my MO, but also NLS and for a while in smart TV.
This days, I no longer doing any of those dot funny stuff. I'm basically coordinating
the team and helping my colleagues to basically work on WebKit.
About the Alia, you probably will see at least another one of these slides today. Sorry
about that. If you don't know, as we are an open social consultancy from the North West
of Spain, found the late 25 years ago, we are distributed this day. We started there. We
have an office, actually, an actual office that not even the people nearby go to, but we are
basically fully remote these days. And we operate an unusual structure where we are basically
active like a cooperative. Everyone ends up being a partner, so basically flat structure.
In the context of this talk, the relevant thing is that we are the second contributor to
the main rendering engines. And in particular, a context of WebKit, I might say if I was
a news to see this year when I checked in the guild of that, like 47 Ecalians contributed
this year to work with, which is amazing. But we also do work on other areas, related
to open source, kernel drivers, compilers, multimedia, many other things. I don't want to
argue with that. So the structure of this presentation, I will try to go really fast on
the first two three points. Mainly because I assume if you are here, you already know
what a web rendering ending is. But yeah, then I will go up and be bring WebKit and
the Linux ports. And then for me, the most interesting part is the is kind of going through
the history of the two projects. And then the latest updates of the past few months and
what we are ahead and next. So super quick, silly, high-level interaction to web rendering
engines, basically, is this thing that takes all the sources from the internet, right?
They fetch that data, interpret that, create internal representations so that they can
work with it and produce a result, they use it and interact with. It's a very, I guess, silly
way of describing them, but it's pretty much it, right? Then it's super complex. And the
main web rendering engines, maybe some people with disagree, but I guess, is fair to say
that WebKit blink for the chromium browser or chromium-based browsers, and get to
core files are the main ones. But I also want to give a shout out to server, because it's
also becoming more and more relevant in particular spaces. But I want to talk much about that,
because this is a webKit talk, and Rego will talk about server just next. So Rego, that's
for you. So what is webKit? So webKit is an open-source rendering
ending, web rendering ending, but just since 2005, because it started as a fork of case
in ML and KJ years from KV project in 2011. In 2008, Google joined, and for five
years, WebKit was used also by chromium browsers, but then in 2013, Google basically
forked it and created blink. The reason is because blink or WebKit for chromium back then
was only interested to be embedded in chromium. While WebKit have a different goal of being
embedded in different platforms, different systems. So basically, they forked and continue
to different paths. But the goals of WebKit remain all around performance, portability.
They usually start, you will see any web rendering ending, but also very important standards
compliance and compatibility for interoperability between browsers. It's very important.
And then besides other things, something very important, I will come in the next slide as
well, which is embedability. It's also available in different platforms, desktop and mobile.
And since 2013 or 2012, it has also this multiple process architecture, where you basically
separate things in different processes. What are the advantages of using WebKit over
other web rendering endings? Well, there are many. I think some of them actually are
also common to other web endings, like performance, security privacy, all those things are
important for all the engines. But for me, one of my favorite is embedded embedability,
let's say, because this is a top priority in WebKit. It's not meant to be used only in,
let's say, Apple browsers. It's meant to be used in different platforms and systems.
And for that reason, it has a maintenance and guarantees of public and stable API that
you can use to build your browser or whatever. And then, all of my second favorite is that
in particular, the Linux flavors of WebKit are independent. In that, there is no big corporation
basically behind us. These are no-pulsor projects. We are the guy who has a lot of work there,
but basically we do work for our customers and for the community and we align the different
goals of everyone in that way. But there is no big corporation mandating this.
So what is the architecture? Again, super simple explanation. You have your application
at the top, you link against WebKit, you use the WebKit API. And that gives you access
to the multi-process architecture, unlike online in Chrome, in Chrome in the multi-process
architecture, it's not in the web and it's not in the link. It's up in the hierarchy.
And here, you already get that by just using WebKit. Then you leverage all the implementation
of the algorithms, the generic algorithms of the Web platform for fetching, for parsing, rendering
layout, that's in the Web corporate. But at some point, you actually have to go into the actual
platform libraries. And that's what this platform box means. It's like the low-level
platforming that connects, let's say, your rendering algorithms with OpenGL or SKIA or whatever.
And then of course, you have JavaScript Correnting, which also supports WebAssembly.
If you now take all these boxes and you actually provide implementations for the low-level
planning in the context of Linux or WebKit, the K-Port, you will see that you are using this
streamer from a Dmitriya, Lipsum from Networking, SKIA for 2D rendering. And so this combination
of the high-level staff, plus the low-level planning, is what it makes what we call
apport, it's another page. And this day is in the context of WebKit, there are several
upstream ports, which lift in the official WebKit repository. These are the Mac ones, the
iOS, Windows, there are playstation as well. And then the two Linux ports, WebKit, K and WP
Kit, which serve two different purposes, as we will see. So, what is WebKit, K? So,
WebKit, K is a port of WebKit for DTK-based applications. So, if you are on Linux and especially
if you are in the num, chances are that you are writing DTK applications and you need something
to use WebKit. But that is it. So, it gives you a fully flat implementation of the
Web platform. So, taking to account this project was born in 2007. So, it is very much
here. So, it has a lot of stuff implemented. And you can use like a regular browser this
day. It also allows you to use hardware acceleration for graphics and multimedia. And this
day is used in many applications, in Genome Web, which is the browser of the num. Evolution,
the mail client, an ID, called Genome Builder, for instance. And what it gives you is this
public API. And the main component there is a GTK with it called the WebKit WebView.
And through this we did basically do everything else. You interact with a WebEnding to
respond to events. And you get all this platform, specific functionality implemented in
terms of the library, as you mentioned before. And of course, you get a JavaScript ending.
And how does it look? It's a bit weird. Like, how does a WebEnding look? But it basically
is the startup responsible for drawing the Web site inside a tap of this Genome Web browser.
So, here is rendering a Web site. Okay. So, where is WP WebKit then? So, WP stands for Web
platform for embedded, that already gives a hint. So, it's basically a part of WebKit
for embedded devices. This started like an idea when back in the time when WebKit
was not good enough for embedded. It has two minutes. So, what if we just take it
K out of the WebKit GTK, produce independence into the minimum and do something that
is more flexible. And that's how this was born. But still, as you can imagine, it's
a lot of common ground with WebKit GTK. So, there are some common parts like a
G-Leaf library, a ski for 2D rendering these days, because just 3 years ago it was
a Skyro. Until 3 years ago, this streamer from multimedia, leaps of foreign networking,
phone company for the rendering. But there are key differences. The main most notable one
is that you don't get a UI to it. You don't get a widget. All you get is this platform
with, and then when you want to deal with input and output for graphics or for whatever
you want to use as an input device, you have to use it through backends. So, that is
flexible enough to whatever kind of device you are building. So, here the focus is slightly
different. So, it's still all the important things from our web engine. You still want
those. Performance, stability, security, but you also want flexibility. A lot of flexibility.
You also want to have as minimum number of dependencies as possible. You also want to
extend things through a backends-based architecture, as I can say before, and you want to
have a really low resource footprint. And then of course, hardware acceleration, especially
on embedded devices, if you can't relieve the CPU of much as possible, does the main thing.
Unfortunately, it depends a lot on the specific software and the specific platform you are
working on. So, you basically, kind of, you have to develop for all of them. But we have
support for support for a lot of them, but not right now. And how it looks? Well, in this
case, what I did is basically, this was in December, I took the top of the tree, I compiled
it, and I ran it it, and this is basically a top of the tree working from this
of December 2025. As you can see, it's just a web view, rendering the web content, there is
no buttons, no nothing, because this is meant to be used in your device. Usually full screen.
So, why the question is, why web engines are so important in embedded? I guess, I mean,
if you think that a web engine is almost like an operating system running onto another operating
system, because it takes so many considerations into account, regarding to render into
security, sandboxing, networking, it gives you an extremely flexible platform to develop
your products. So, it gives you a lot of flexibility for design and implementation your platform.
And all of that, you can do it on top of a very well known development stack, which is
a web platform. And so, there's no surprise that people these days are building all sort
of things, with that, it's not just, as you can imagine, maybe set of boxes and phones, set
of boxes is huge, by the way, we are talking about hundreds of millions of devices out there
using what the knowledge is in specifically WP. But, just cooking machines for instance,
who will hunt no bridges, GPS devices, even some people are using WP that I know, for
how your systems with no screens, just to consume music streaming services from the internet
and play those through your speakers. So, it's an QI, of course, as well. So, that's planning
a lot of, plenty of usages that you can do. So, sorry for going too fast, I really wanted
to come here. So, this two-poor share a lot of ground. And I think it's nice to understand
what we are doing right now and why we didn't do it before, maybe, it's good to see the
history. So, in 2007, a WP GTK port was born, back then, a genome has this epiphany
browser that it was built on top of a get-go. And get-go was fine. The problem with get-go
similar to blink, I guess, these days, is that it was never conceived to be embeddable
from different applications. It wasn't meant to be used from five of us. So, it was not
a problem to break the API if that's what five was needed. And that's okay, for now Mozilla
and a high first point of view, that's perfectly fine. But, when get-go, I wanted to use
this for, for, for, for epiphany, it was a mess, because any time that the API broke, you
will have issues. So, in 2007, I've talked about, from the get-go community, decided
to start this project and as a replacement for get-go on epiphany, which actually happened
in 2009. At the same year, that also, they started with live-goer, I think, for network,
and that year also migrated to live-su, which is a genome-friendly network library. So, on
2009, epiphany finally, in go-other place, got-goer, quit replacing get-go. In 2010, it was
another important year, because, yeah, in 2009, it was cool, but, and work is dedicated
back then, only have one process. That meant that if you have multiple tabs and your
web content press, there goes your browser, your entire browser, it doesn't matter. If you
think back in 2009, there was already, in Chrome, in the already existing, in Chrome,
in Chrome, in the already came, with this idea of multiple press processes. You break one
tab, you don't break your browser. And that's an interesting concept, right? So, in 2010,
the web community announced the WebKit 2 project, which was meant to bring the multi-process
architecture as well. And WebKit 2, of course, started working on that. But it was not until
2013 that the WebKit 2 project actually released a first version with WebKit 2, with
the multi-process model. Then, in 2014, we faced out the single-process version, and this
year is something interesting happening. It's identity-pated a little bit before. What if
we remove GTK from WebKit 2, and try to make it more friendly for embedded devices?
And at that day, the environment where this idea was born was using WebLAN. So, why don't
we just use WebLAN directly? And paint directly there. And that's how WebKit for WebLAN
was born, which before it wasn't whole WP. So, now, first for what a few years, WebKit
2, GTK and WP kept evolving in parallel, many of the benefits in one port, in part the other
port, of course. And in 2017, WebKit for WebLAN was renamed into WGP, because that year
was, okay, what if we just don't need to use WebLAN? We might also want to use X-Living,
or DRM, or just Hullis, or whatever. So, it was renamed into this. And until this point
WGP was living in a downstream repository. And this year was also important, because it
was when WP made it to the official upstream WebKit repository, and it became an official
port. So, first for where again, five years, two ports kept working, kept developing,
developing in parallel, WGP took massive adoption in the embedded space. But something was
missing, and we realized, like, we hit kind of a wall. Like, many things were improving,
but there was this particular thing that was nagging in the project a lot, which is the
2D rendering. Until this point, WebKit was based on KIDO. KIDO was a fine 2D rendering library,
but didn't didn't allow hardware acceleration, and also it was not well maintained. So,
and at this time, we started thinking, what if we do something else? Kind of the obvious idea is,
oh, why don't we move to skier? But skier also, we consider it, and also had other issues. So,
we started a bunch of things in parallel, that I would summarize it, like a set of major
factors around the graphics and start, including exploring the idea of maybe writing our
round to the rendering library, taking skier, see what makes sense. Also, on our mention, to the fact
that that year, we also started playing, again, with the idea of a run in WP on top of Android.
So, that you could have an opportunity to use WebKit on Android devices, that if you didn't
realize, it's not an option right now. So, this year, something, this is started, and we
started on a series of hectic years, right after that. So, 2023 is the year where we added
support for WebDL2, based on angle. We added support for DMA, but this was massive, because allows
a 0,0 copy of our sharing, not just for graphics, also for multimedia. We started implementing
this GPU process that I show in the one of the initial slides. That 2014 was kind of a key
key point. This is the year where we realized that actually, we think it makes sense to move to skier,
we talk to the skier developers, we talk to the working community, we didn't make this decision
likely. You can't believe many people in the team that are now very happy with the change
work really opposed to this, but we made a change. It turns out that it's happened, it
worked better than we were expecting. It seems that if you take a 2-DF in library,
specifically designed for browsers, it works pretty well. We also started implementing a new
API, because we realized that the old WAPI was too complex and very limited, and didn't allow
to do things that we wanted to do, so we also started implementing a new API that makes everything
much easier to use. And yeah, bonus points, we also work on a hardware accelerated SVT engine,
that what it doesn't have to this day. We are working still working on that.
2025, I will summarize it better in the next slide, but just to keep your glimpse, we kept doing a lot
of major effectiveness in graphics, the platform, this new WAPI material, and WP Android also
became even more and more stable, and now it's becoming to be a thing. So yeah, if you look
at this timeline, you realize that there were like 2 big 5-DR gaps, and then something happened
2022, and now we are in a really good momentum here, and working in Linux, this means
that working in Linux is better than ever right now. So what happened in the last 12 months?
So first of all, they usual to the stable releases, we have a 6-month cadence for releases in
WAPI GTK and WDP, they have been at the same time, they bring all the usual good stuff from the
WAPI, multimedia improvements, mostly around web code, web audio, and also in just three
different base, WebRTC backend as well. And then, as I mentioned before, a few
which overhaul on the graphics side, like we removed abstraction layers that were in the needed,
and simplified the code base, we added threaded GPU rendering, we enabled by the full GPU
process for WAPGL, only just for now, and we did huge improvements on the damage tracking,
information using this information not just for the two different industrial stations, but also
through the whole pipeline, even during the composition. This is massive in embedded, in terms of
performance gains. And if you don't believe me, you can see this. This is how it looks on the left
is July 2024, on the right is now. So it's a year and a half, and this is for the Raspberry Pi 32
beat and 64 beat. If you see the numbers on the overall score, it's a 3x improvement on the
graphics performance using the motion map. It's massive. If you go into the individual tests,
you see some of them are not that impressive, but then you look at paths that increase by, I think,
11, something times better. And this is just with one year and a half. This is what happens with
you, when you finally, you know, do these kind of changes that were over the years in the graphics
side. But we are not done with that. Then many other things, in the JavaScript world,
memory related changes and improvements, tooling, web assembly, security as well.
And quality assurance, this special mention, especially this past year, we did a huge
revamp of the full QA infrastructure, and now we have both that are more reliable than ever. That
is also important because it doesn't matter that you do your best and you create a good product that
if nobody realizes when it's crashing, it's breaking. The new WPAPIS, I mentioned, we nearly finished
actually, I say this because the plan was to release the stable now in the release of match. But
on a second thought, we, we thought that we might give it another, we will give it another cycle
to to finish, to get finished, and it will be released in September unless something really,
really weird happens. But we did a lot of stuff in this cycle as well. Android, I don't have time,
but there is, we started back then, this product called WP Android, which is like a web view,
that sits on top of WP, you can use some Android devices, but it's not in the WebP itself,
and it started as an experiment, so it contained actually a few patches inside WebPit and that
we were needed. So during this cycle, those patches were all moved, I've stringed to WebPin, no longer
in an external repository. Also, there is now support for a hardware factor, which is the equivalent
of TMAV, or kind of, in Android, and many other things, and we kept evolving, of course, the WP Android project.
And then, if this was not enough, we also, this year, we got an opportunity to improve the
support of WebExR, and implemented an OpenXR-based support, and enable it for Linux and Android as well.
So now you can actually see virtual reality and augmented reality experiences using WebPit on Linux.
So, I need to get going, I guess. So, what are we doing now? I said, I mean, we are in a really good
moment, and we don't want to stop. We have so many ideas, we are managing to align people, to help
us, keep developing things, and yeah, we are going to keep doing this stuff. Like, on multi-media,
we're going to keep working around the usual suspects. On graphics, we have lots of ideas,
one of the main things is that we want to align the graphics architecture with other ports.
This means that, if, for instance, the Mac and the iOS ports do something that is cool,
we can also benefit. I mean, we are as multi-in, and it makes sense to align as much as possible
with other teams. In particular, we also want to have the possibility of using modern graphics
APIs, in particular, Vulkan, which are the door to using things like WebGPU,
several improvements around asynchronous programming animations. While these are specific examples,
I guess, the one that I also think is relevant is to mention that this year, it will be the year
that we will remove tighter support. But don't worry, I mean, we talk to the stakeholders,
they only main thing that is pending is a big Indian support. Turns out not many people are using that,
but there are some people, and we are talking to them, and there is a plan for that. But the plan
is here is that from upstream, there won't be more tighter support. More changes around JavaScript,
like more memory improvements, more tooling, security is the same thing. We will keep doing
security advisories and backfills releases, and we will also keep improving smart-pointed
cobras to reduce unsafe access. I did mention, but it wasn't as live before this year, we also
remove live support, and we are using live support three. And quality assurance, we've
revamped the following infrastructure the past year. This year, the plan is to keep improving it,
but also to improve the way we maintain the CIWOT's healthy. Relief, the WGP API, this time is for real.
I think it's going to be in September. Android support, we will continue doing this. We will finish
the migration to the new API, which is crucial to be able to use also 0.0 copy buffer sharing.
And the idea is to integrate it also with the WGP testing infrastructure, let's see.
And then for WebExR, we will continue there. So, this take into the last slide promise?
So, the message I want to deliver here today. I know this is a very high level. It's not super
technical, especially after all the talks here. I don't want to sell you anything, but
the truth is that we are in a really good moment for WebExR. It hasn't been always like that,
but we are now in a really good moment. We have a complete implementation with a web platform
that you can use on GTK application super easy. On other applications, you can use WGP.
WGP comes with back and so ready for well and DRM and headless, but nothing prevents you to
create your RM backend. We actually created a GTK for backend, just as an experiment,
so that you can actually use WGP now easily as well on GTK applications.
If you pay attention to the history, you realize that those these ports are very much your
very actively maintained. And the last 4 years were crucial, and now the next years are going to
be the plan is to keep working around this line. So, we got to a great point now we want to keep
improving, not just performance, but also we want to make sure that this is a great product.
It's a great product now, but we want it to keep being a great product. So that's why we are going
to put this year, especially on anything related to QI and maintenance. And yeah, pretty exciting, I guess.
And yeah, and that's it, I think. I made it in 26. Sorry about that.
All right, maybe we can do one question, because we don't have the thing. Patrick?
My question is around the six-month release cadence. I was wondering whether you could say where
these cadence was coming from. Yeah, that's a clear answer. So, WGDK has started as you saw with
very tiny integrated with a non-project. And this basically aligns with the cadence of the releases
of the non-project as well. So the idea is that more or less marked September, which is also when
the non-cams with the releases, we also can with the WGDDK releases. So everything is aligned.
Perfect. Thank you so much. It's been great. Thank you.
Thank you.