WEBVTT 00:00.000 --> 00:11.000 Okay, everyone. Welcome. We're going to start this talk two minutes early because Mario 00:11.000 --> 00:18.000 is going to need some more time to talk about WebKit. Right. Mario, over to you. 00:18.000 --> 00:25.360 Thank you. Hello. Thanks for coming here. The purpose of this talk is not to go very deep 00:25.360 --> 00:29.920 into technicalities, but basically keep a kind of an overview of where we are in the context 00:29.920 --> 00:34.960 of WebKit and Linux. My name is Mario. I'm suffering in the near. I've been working in 00:34.960 --> 00:39.640 the Alia for quite a while. I'm also a partner of the company. I've been working mostly 00:39.640 --> 00:44.640 on open social my life around genomes. I did a lot of working WebKit and Chromium and WebKit 00:44.640 --> 00:51.280 again. And I also, this is also because I like it. I work a lot on Linux based operating systems 00:51.280 --> 00:57.080 mainly, if you remember the Nokia times on my MO, but also NLS and for a while in smart TV. 00:57.080 --> 01:01.360 This days, I no longer doing any of those dot funny stuff. I'm basically coordinating 01:01.360 --> 01:06.480 the team and helping my colleagues to basically work on WebKit. 01:06.480 --> 01:10.480 About the Alia, you probably will see at least another one of these slides today. Sorry 01:10.480 --> 01:14.520 about that. If you don't know, as we are an open social consultancy from the North West 01:14.520 --> 01:19.400 of Spain, found the late 25 years ago, we are distributed this day. We started there. We 01:19.440 --> 01:24.960 have an office, actually, an actual office that not even the people nearby go to, but we are 01:24.960 --> 01:29.440 basically fully remote these days. And we operate an unusual structure where we are basically 01:29.440 --> 01:36.280 active like a cooperative. Everyone ends up being a partner, so basically flat structure. 01:36.280 --> 01:40.160 In the context of this talk, the relevant thing is that we are the second contributor to 01:40.160 --> 01:44.720 the main rendering engines. And in particular, a context of WebKit, I might say if I was 01:44.720 --> 01:49.400 a news to see this year when I checked in the guild of that, like 47 Ecalians contributed 01:49.400 --> 01:53.480 this year to work with, which is amazing. But we also do work on other areas, related 01:53.480 --> 02:00.040 to open source, kernel drivers, compilers, multimedia, many other things. I don't want to 02:00.040 --> 02:06.160 argue with that. So the structure of this presentation, I will try to go really fast on 02:06.160 --> 02:10.200 the first two three points. Mainly because I assume if you are here, you already know 02:10.200 --> 02:15.280 what a web rendering ending is. But yeah, then I will go up and be bring WebKit and 02:15.280 --> 02:20.160 the Linux ports. And then for me, the most interesting part is the is kind of going through 02:20.160 --> 02:25.000 the history of the two projects. And then the latest updates of the past few months and 02:25.000 --> 02:32.200 what we are ahead and next. So super quick, silly, high-level interaction to web rendering 02:32.200 --> 02:36.560 engines, basically, is this thing that takes all the sources from the internet, right? 02:36.560 --> 02:41.160 They fetch that data, interpret that, create internal representations so that they can 02:41.160 --> 02:46.000 work with it and produce a result, they use it and interact with. It's a very, I guess, silly 02:46.000 --> 02:51.360 way of describing them, but it's pretty much it, right? Then it's super complex. And the 02:51.360 --> 02:55.520 main web rendering engines, maybe some people with disagree, but I guess, is fair to say 02:55.520 --> 03:01.960 that WebKit blink for the chromium browser or chromium-based browsers, and get to 03:01.960 --> 03:07.760 core files are the main ones. But I also want to give a shout out to server, because it's 03:07.760 --> 03:13.240 also becoming more and more relevant in particular spaces. But I want to talk much about that, 03:13.240 --> 03:17.640 because this is a webKit talk, and Rego will talk about server just next. So Rego, that's 03:17.640 --> 03:22.880 for you. So what is webKit? So webKit is an open-source rendering 03:22.880 --> 03:29.920 ending, web rendering ending, but just since 2005, because it started as a fork of case 03:29.920 --> 03:37.520 in ML and KJ years from KV project in 2011. In 2008, Google joined, and for five 03:37.520 --> 03:44.200 years, WebKit was used also by chromium browsers, but then in 2013, Google basically 03:44.200 --> 03:51.680 forked it and created blink. The reason is because blink or WebKit for chromium back then 03:51.680 --> 03:56.360 was only interested to be embedded in chromium. While WebKit have a different goal of being 03:56.360 --> 04:01.280 embedded in different platforms, different systems. So basically, they forked and continue 04:01.280 --> 04:06.880 to different paths. But the goals of WebKit remain all around performance, portability. 04:06.880 --> 04:12.680 They usually start, you will see any web rendering ending, but also very important standards 04:12.680 --> 04:18.000 compliance and compatibility for interoperability between browsers. It's very important. 04:18.000 --> 04:21.560 And then besides other things, something very important, I will come in the next slide as 04:21.560 --> 04:27.440 well, which is embedability. It's also available in different platforms, desktop and mobile. 04:27.440 --> 04:35.240 And since 2013 or 2012, it has also this multiple process architecture, where you basically 04:35.240 --> 04:40.240 separate things in different processes. What are the advantages of using WebKit over 04:40.240 --> 04:45.160 other web rendering endings? Well, there are many. I think some of them actually are 04:45.160 --> 04:49.360 also common to other web endings, like performance, security privacy, all those things are 04:49.360 --> 04:53.640 important for all the engines. But for me, one of my favorite is embedded embedability, 04:53.640 --> 04:57.840 let's say, because this is a top priority in WebKit. It's not meant to be used only in, 04:57.840 --> 05:02.600 let's say, Apple browsers. It's meant to be used in different platforms and systems. 05:02.600 --> 05:07.680 And for that reason, it has a maintenance and guarantees of public and stable API that 05:07.680 --> 05:13.240 you can use to build your browser or whatever. And then, all of my second favorite is that 05:13.240 --> 05:18.960 in particular, the Linux flavors of WebKit are independent. In that, there is no big corporation 05:18.960 --> 05:23.960 basically behind us. These are no-pulsor projects. We are the guy who has a lot of work there, 05:23.960 --> 05:28.360 but basically we do work for our customers and for the community and we align the different 05:28.360 --> 05:34.560 goals of everyone in that way. But there is no big corporation mandating this. 05:34.560 --> 05:38.440 So what is the architecture? Again, super simple explanation. You have your application 05:38.440 --> 05:43.600 at the top, you link against WebKit, you use the WebKit API. And that gives you access 05:43.600 --> 05:48.480 to the multi-process architecture, unlike online in Chrome, in Chrome in the multi-process 05:48.480 --> 05:52.960 architecture, it's not in the web and it's not in the link. It's up in the hierarchy. 05:52.960 --> 05:58.320 And here, you already get that by just using WebKit. Then you leverage all the implementation 05:58.320 --> 06:03.360 of the algorithms, the generic algorithms of the Web platform for fetching, for parsing, rendering 06:03.360 --> 06:08.680 layout, that's in the Web corporate. But at some point, you actually have to go into the actual 06:08.680 --> 06:12.600 platform libraries. And that's what this platform box means. It's like the low-level 06:12.600 --> 06:20.040 platforming that connects, let's say, your rendering algorithms with OpenGL or SKIA or whatever. 06:20.040 --> 06:24.800 And then of course, you have JavaScript Correnting, which also supports WebAssembly. 06:24.800 --> 06:29.760 If you now take all these boxes and you actually provide implementations for the low-level 06:29.760 --> 06:35.480 planning in the context of Linux or WebKit, the K-Port, you will see that you are using this 06:35.480 --> 06:41.280 streamer from a Dmitriya, Lipsum from Networking, SKIA for 2D rendering. And so this combination 06:41.280 --> 06:46.760 of the high-level staff, plus the low-level planning, is what it makes what we call 06:46.760 --> 06:51.680 apport, it's another page. And this day is in the context of WebKit, there are several 06:51.680 --> 06:57.520 upstream ports, which lift in the official WebKit repository. These are the Mac ones, the 06:57.520 --> 07:03.940 iOS, Windows, there are playstation as well. And then the two Linux ports, WebKit, K and WP 07:03.940 --> 07:13.640 Kit, which serve two different purposes, as we will see. So, what is WebKit, K? So, 07:13.640 --> 07:20.020 WebKit, K is a port of WebKit for DTK-based applications. So, if you are on Linux and especially 07:20.020 --> 07:23.780 if you are in the num, chances are that you are writing DTK applications and you need something 07:23.780 --> 07:29.660 to use WebKit. But that is it. So, it gives you a fully flat implementation of the 07:29.660 --> 07:33.920 Web platform. So, taking to account this project was born in 2007. So, it is very much 07:33.920 --> 07:38.660 here. So, it has a lot of stuff implemented. And you can use like a regular browser this 07:38.660 --> 07:44.540 day. It also allows you to use hardware acceleration for graphics and multimedia. And this 07:44.540 --> 07:50.100 day is used in many applications, in Genome Web, which is the browser of the num. Evolution, 07:50.100 --> 07:55.020 the mail client, an ID, called Genome Builder, for instance. And what it gives you is this 07:55.020 --> 08:00.420 public API. And the main component there is a GTK with it called the WebKit WebView. 08:00.420 --> 08:04.900 And through this we did basically do everything else. You interact with a WebEnding to 08:04.900 --> 08:10.620 respond to events. And you get all this platform, specific functionality implemented in 08:10.620 --> 08:15.900 terms of the library, as you mentioned before. And of course, you get a JavaScript ending. 08:15.900 --> 08:21.620 And how does it look? It's a bit weird. Like, how does a WebEnding look? But it basically 08:21.620 --> 08:27.620 is the startup responsible for drawing the Web site inside a tap of this Genome Web browser. 08:27.620 --> 08:36.840 So, here is rendering a Web site. Okay. So, where is WP WebKit then? So, WP stands for Web 08:36.840 --> 08:42.620 platform for embedded, that already gives a hint. So, it's basically a part of WebKit 08:42.620 --> 08:49.500 for embedded devices. This started like an idea when back in the time when WebKit 08:49.740 --> 08:53.860 was not good enough for embedded. It has two minutes. So, what if we just take it 08:53.860 --> 08:59.340 K out of the WebKit GTK, produce independence into the minimum and do something that 08:59.340 --> 09:04.180 is more flexible. And that's how this was born. But still, as you can imagine, it's 09:04.180 --> 09:09.060 a lot of common ground with WebKit GTK. So, there are some common parts like a 09:09.060 --> 09:14.500 G-Leaf library, a ski for 2D rendering these days, because just 3 years ago it was 09:14.500 --> 09:19.580 a Skyro. Until 3 years ago, this streamer from multimedia, leaps of foreign networking, 09:19.580 --> 09:24.900 phone company for the rendering. But there are key differences. The main most notable one 09:24.900 --> 09:31.180 is that you don't get a UI to it. You don't get a widget. All you get is this platform 09:31.180 --> 09:37.420 with, and then when you want to deal with input and output for graphics or for whatever 09:37.420 --> 09:41.580 you want to use as an input device, you have to use it through backends. So, that is 09:41.580 --> 09:47.180 flexible enough to whatever kind of device you are building. So, here the focus is slightly 09:47.180 --> 09:50.260 different. So, it's still all the important things from our web engine. You still want 09:50.260 --> 09:55.780 those. Performance, stability, security, but you also want flexibility. A lot of flexibility. 09:55.780 --> 10:01.820 You also want to have as minimum number of dependencies as possible. You also want to 10:01.820 --> 10:06.820 extend things through a backends-based architecture, as I can say before, and you want to 10:06.820 --> 10:11.220 have a really low resource footprint. And then of course, hardware acceleration, especially 10:11.220 --> 10:15.980 on embedded devices, if you can't relieve the CPU of much as possible, does the main thing. 10:15.980 --> 10:20.620 Unfortunately, it depends a lot on the specific software and the specific platform you are 10:20.620 --> 10:25.620 working on. So, you basically, kind of, you have to develop for all of them. But we have 10:25.620 --> 10:32.300 support for support for a lot of them, but not right now. And how it looks? Well, in this 10:32.300 --> 10:38.260 case, what I did is basically, this was in December, I took the top of the tree, I compiled 10:38.260 --> 10:43.140 it, and I ran it it, and this is basically a top of the tree working from this 10:43.140 --> 10:49.260 of December 2025. As you can see, it's just a web view, rendering the web content, there is 10:49.260 --> 10:56.900 no buttons, no nothing, because this is meant to be used in your device. Usually full screen. 10:56.900 --> 11:03.460 So, why the question is, why web engines are so important in embedded? I guess, I mean, 11:03.460 --> 11:08.140 if you think that a web engine is almost like an operating system running onto another operating 11:08.140 --> 11:12.740 system, because it takes so many considerations into account, regarding to render into 11:12.740 --> 11:19.060 security, sandboxing, networking, it gives you an extremely flexible platform to develop 11:19.060 --> 11:24.340 your products. So, it gives you a lot of flexibility for design and implementation your platform. 11:24.340 --> 11:29.220 And all of that, you can do it on top of a very well known development stack, which is 11:29.220 --> 11:33.900 a web platform. And so, there's no surprise that people these days are building all sort 11:33.900 --> 11:38.580 of things, with that, it's not just, as you can imagine, maybe set of boxes and phones, set 11:38.580 --> 11:44.100 of boxes is huge, by the way, we are talking about hundreds of millions of devices out there 11:44.100 --> 11:49.820 using what the knowledge is in specifically WP. But, just cooking machines for instance, 11:49.820 --> 11:58.620 who will hunt no bridges, GPS devices, even some people are using WP that I know, for 11:58.620 --> 12:05.620 how your systems with no screens, just to consume music streaming services from the internet 12:05.620 --> 12:10.980 and play those through your speakers. So, it's an QI, of course, as well. So, that's planning 12:10.980 --> 12:18.620 a lot of, plenty of usages that you can do. So, sorry for going too fast, I really wanted 12:18.620 --> 12:25.460 to come here. So, this two-poor share a lot of ground. And I think it's nice to understand 12:25.940 --> 12:30.580 what we are doing right now and why we didn't do it before, maybe, it's good to see the 12:30.580 --> 12:38.740 history. So, in 2007, a WP GTK port was born, back then, a genome has this epiphany 12:38.740 --> 12:44.220 browser that it was built on top of a get-go. And get-go was fine. The problem with get-go 12:44.220 --> 12:50.220 similar to blink, I guess, these days, is that it was never conceived to be embeddable 12:50.220 --> 12:55.140 from different applications. It wasn't meant to be used from five of us. So, it was not 12:55.140 --> 13:00.500 a problem to break the API if that's what five was needed. And that's okay, for now Mozilla 13:00.500 --> 13:04.220 and a high first point of view, that's perfectly fine. But, when get-go, I wanted to use 13:04.220 --> 13:10.540 this for, for, for, for epiphany, it was a mess, because any time that the API broke, you 13:10.540 --> 13:16.380 will have issues. So, in 2007, I've talked about, from the get-go community, decided 13:16.380 --> 13:22.420 to start this project and as a replacement for get-go on epiphany, which actually happened 13:22.420 --> 13:28.620 in 2009. At the same year, that also, they started with live-goer, I think, for network, 13:28.620 --> 13:34.060 and that year also migrated to live-su, which is a genome-friendly network library. So, on 13:34.060 --> 13:42.140 2009, epiphany finally, in go-other place, got-goer, quit replacing get-go. In 2010, it was 13:42.140 --> 13:46.940 another important year, because, yeah, in 2009, it was cool, but, and work is dedicated 13:46.940 --> 13:51.260 back then, only have one process. That meant that if you have multiple tabs and your 13:51.260 --> 13:57.140 web content press, there goes your browser, your entire browser, it doesn't matter. If you 13:57.140 --> 14:01.220 think back in 2009, there was already, in Chrome, in the already existing, in Chrome, 14:01.220 --> 14:05.740 in Chrome, in the already came, with this idea of multiple press processes. You break one 14:05.740 --> 14:09.860 tab, you don't break your browser. And that's an interesting concept, right? So, in 2010, 14:09.860 --> 14:14.860 the web community announced the WebKit 2 project, which was meant to bring the multi-process 14:14.860 --> 14:21.140 architecture as well. And WebKit 2, of course, started working on that. But it was not until 14:21.140 --> 14:28.540 2013 that the WebKit 2 project actually released a first version with WebKit 2, with 14:28.540 --> 14:35.660 the multi-process model. Then, in 2014, we faced out the single-process version, and this 14:35.660 --> 14:39.980 year is something interesting happening. It's identity-pated a little bit before. What if 14:39.980 --> 14:45.820 we remove GTK from WebKit 2, and try to make it more friendly for embedded devices? 14:45.820 --> 14:51.820 And at that day, the environment where this idea was born was using WebLAN. So, why don't 14:51.820 --> 14:56.060 we just use WebLAN directly? And paint directly there. And that's how WebKit for WebLAN 14:56.060 --> 15:03.040 was born, which before it wasn't whole WP. So, now, first for what a few years, WebKit 15:03.040 --> 15:09.240 2, GTK and WP kept evolving in parallel, many of the benefits in one port, in part the other 15:09.240 --> 15:18.000 port, of course. And in 2017, WebKit for WebLAN was renamed into WGP, because that year 15:18.000 --> 15:24.240 was, okay, what if we just don't need to use WebLAN? We might also want to use X-Living, 15:24.240 --> 15:29.940 or DRM, or just Hullis, or whatever. So, it was renamed into this. And until this point 15:30.020 --> 15:34.900 WGP was living in a downstream repository. And this year was also important, because it 15:34.900 --> 15:40.020 was when WP made it to the official upstream WebKit repository, and it became an official 15:40.020 --> 15:49.020 port. So, first for where again, five years, two ports kept working, kept developing, 15:49.020 --> 15:56.220 developing in parallel, WGP took massive adoption in the embedded space. But something was 15:56.300 --> 16:00.300 missing, and we realized, like, we hit kind of a wall. Like, many things were improving, 16:00.300 --> 16:05.420 but there was this particular thing that was nagging in the project a lot, which is the 16:05.420 --> 16:12.380 2D rendering. Until this point, WebKit was based on KIDO. KIDO was a fine 2D rendering library, 16:12.380 --> 16:18.460 but didn't didn't allow hardware acceleration, and also it was not well maintained. So, 16:18.460 --> 16:23.180 and at this time, we started thinking, what if we do something else? Kind of the obvious idea is, 16:23.260 --> 16:29.580 oh, why don't we move to skier? But skier also, we consider it, and also had other issues. So, 16:29.580 --> 16:35.980 we started a bunch of things in parallel, that I would summarize it, like a set of major 16:35.980 --> 16:41.100 factors around the graphics and start, including exploring the idea of maybe writing our 16:41.100 --> 16:48.780 round to the rendering library, taking skier, see what makes sense. Also, on our mention, to the fact 16:48.860 --> 16:54.300 that that year, we also started playing, again, with the idea of a run in WP on top of Android. 16:54.300 --> 16:59.260 So, that you could have an opportunity to use WebKit on Android devices, that if you didn't 16:59.260 --> 17:05.420 realize, it's not an option right now. So, this year, something, this is started, and we 17:05.420 --> 17:12.460 started on a series of hectic years, right after that. So, 2023 is the year where we added 17:12.460 --> 17:17.580 support for WebDL2, based on angle. We added support for DMA, but this was massive, because allows 17:17.580 --> 17:23.180 a 0,0 copy of our sharing, not just for graphics, also for multimedia. We started implementing 17:23.180 --> 17:30.300 this GPU process that I show in the one of the initial slides. That 2014 was kind of a key 17:30.940 --> 17:35.500 key point. This is the year where we realized that actually, we think it makes sense to move to skier, 17:35.500 --> 17:40.940 we talk to the skier developers, we talk to the working community, we didn't make this decision 17:40.940 --> 17:44.780 likely. You can't believe many people in the team that are now very happy with the change 17:44.780 --> 17:49.500 work really opposed to this, but we made a change. It turns out that it's happened, it 17:49.500 --> 17:54.220 worked better than we were expecting. It seems that if you take a 2-DF in library, 17:54.220 --> 18:03.580 specifically designed for browsers, it works pretty well. We also started implementing a new 18:03.580 --> 18:10.060 API, because we realized that the old WAPI was too complex and very limited, and didn't allow 18:10.060 --> 18:15.260 to do things that we wanted to do, so we also started implementing a new API that makes everything 18:15.260 --> 18:22.220 much easier to use. And yeah, bonus points, we also work on a hardware accelerated SVT engine, 18:22.220 --> 18:25.420 that what it doesn't have to this day. We are working still working on that. 18:26.620 --> 18:32.300 2025, I will summarize it better in the next slide, but just to keep your glimpse, we kept doing a lot 18:32.300 --> 18:40.300 of major effectiveness in graphics, the platform, this new WAPI material, and WP Android also 18:40.300 --> 18:46.380 became even more and more stable, and now it's becoming to be a thing. So yeah, if you look 18:46.380 --> 18:51.020 at this timeline, you realize that there were like 2 big 5-DR gaps, and then something happened 18:51.020 --> 18:56.380 2022, and now we are in a really good momentum here, and working in Linux, this means 18:56.380 --> 19:03.100 that working in Linux is better than ever right now. So what happened in the last 12 months? 19:03.100 --> 19:09.500 So first of all, they usual to the stable releases, we have a 6-month cadence for releases in 19:09.500 --> 19:14.540 WAPI GTK and WDP, they have been at the same time, they bring all the usual good stuff from the 19:14.540 --> 19:20.700 WAPI, multimedia improvements, mostly around web code, web audio, and also in just three 19:20.780 --> 19:25.820 different base, WebRTC backend as well. And then, as I mentioned before, a few 19:25.820 --> 19:30.140 which overhaul on the graphics side, like we removed abstraction layers that were in the needed, 19:30.140 --> 19:35.660 and simplified the code base, we added threaded GPU rendering, we enabled by the full GPU 19:35.660 --> 19:41.340 process for WAPGL, only just for now, and we did huge improvements on the damage tracking, 19:42.780 --> 19:47.020 information using this information not just for the two different industrial stations, but also 19:47.100 --> 19:51.660 through the whole pipeline, even during the composition. This is massive in embedded, in terms of 19:51.660 --> 19:57.180 performance gains. And if you don't believe me, you can see this. This is how it looks on the left 19:57.180 --> 20:04.140 is July 2024, on the right is now. So it's a year and a half, and this is for the Raspberry Pi 32 20:04.140 --> 20:09.820 beat and 64 beat. If you see the numbers on the overall score, it's a 3x improvement on the 20:09.820 --> 20:14.140 graphics performance using the motion map. It's massive. If you go into the individual tests, 20:15.100 --> 20:20.780 you see some of them are not that impressive, but then you look at paths that increase by, I think, 20:20.780 --> 20:26.460 11, something times better. And this is just with one year and a half. This is what happens with 20:26.460 --> 20:33.180 you, when you finally, you know, do these kind of changes that were over the years in the graphics 20:33.180 --> 20:37.420 side. But we are not done with that. Then many other things, in the JavaScript world, 20:38.380 --> 20:43.900 memory related changes and improvements, tooling, web assembly, security as well. 20:45.740 --> 20:49.980 And quality assurance, this special mention, especially this past year, we did a huge 20:49.980 --> 20:54.220 revamp of the full QA infrastructure, and now we have both that are more reliable than ever. That 20:54.220 --> 20:59.020 is also important because it doesn't matter that you do your best and you create a good product that 20:59.020 --> 21:06.940 if nobody realizes when it's crashing, it's breaking. The new WPAPIS, I mentioned, we nearly finished 21:07.020 --> 21:12.380 actually, I say this because the plan was to release the stable now in the release of match. But 21:12.380 --> 21:18.140 on a second thought, we, we thought that we might give it another, we will give it another cycle 21:18.140 --> 21:25.500 to to finish, to get finished, and it will be released in September unless something really, 21:25.500 --> 21:32.540 really weird happens. But we did a lot of stuff in this cycle as well. Android, I don't have time, 21:32.540 --> 21:39.260 but there is, we started back then, this product called WP Android, which is like a web view, 21:39.260 --> 21:43.820 that sits on top of WP, you can use some Android devices, but it's not in the WebP itself, 21:43.820 --> 21:49.340 and it started as an experiment, so it contained actually a few patches inside WebPit and that 21:49.340 --> 21:53.660 we were needed. So during this cycle, those patches were all moved, I've stringed to WebPin, no longer 21:53.660 --> 21:59.340 in an external repository. Also, there is now support for a hardware factor, which is the equivalent 21:59.340 --> 22:05.500 of TMAV, or kind of, in Android, and many other things, and we kept evolving, of course, the WP Android project. 22:07.020 --> 22:12.140 And then, if this was not enough, we also, this year, we got an opportunity to improve the 22:12.140 --> 22:18.220 support of WebExR, and implemented an OpenXR-based support, and enable it for Linux and Android as well. 22:18.220 --> 22:23.820 So now you can actually see virtual reality and augmented reality experiences using WebPit on Linux. 22:24.700 --> 22:34.380 So, I need to get going, I guess. So, what are we doing now? I said, I mean, we are in a really good 22:34.380 --> 22:40.380 moment, and we don't want to stop. We have so many ideas, we are managing to align people, to help 22:40.380 --> 22:46.380 us, keep developing things, and yeah, we are going to keep doing this stuff. Like, on multi-media, 22:46.380 --> 22:53.020 we're going to keep working around the usual suspects. On graphics, we have lots of ideas, 22:53.420 --> 22:57.900 one of the main things is that we want to align the graphics architecture with other ports. 22:57.900 --> 23:02.700 This means that, if, for instance, the Mac and the iOS ports do something that is cool, 23:02.700 --> 23:08.060 we can also benefit. I mean, we are as multi-in, and it makes sense to align as much as possible 23:08.060 --> 23:14.620 with other teams. In particular, we also want to have the possibility of using modern graphics 23:14.620 --> 23:18.860 APIs, in particular, Vulkan, which are the door to using things like WebGPU, 23:19.820 --> 23:25.100 several improvements around asynchronous programming animations. While these are specific examples, 23:25.100 --> 23:29.980 I guess, the one that I also think is relevant is to mention that this year, it will be the year 23:29.980 --> 23:35.260 that we will remove tighter support. But don't worry, I mean, we talk to the stakeholders, 23:35.260 --> 23:41.580 they only main thing that is pending is a big Indian support. Turns out not many people are using that, 23:41.580 --> 23:46.300 but there are some people, and we are talking to them, and there is a plan for that. But the plan 23:46.300 --> 23:54.060 is here is that from upstream, there won't be more tighter support. More changes around JavaScript, 23:54.060 --> 23:59.260 like more memory improvements, more tooling, security is the same thing. We will keep doing 23:59.260 --> 24:04.940 security advisories and backfills releases, and we will also keep improving smart-pointed 24:04.940 --> 24:10.300 cobras to reduce unsafe access. I did mention, but it wasn't as live before this year, we also 24:10.300 --> 24:17.020 remove live support, and we are using live support three. And quality assurance, we've 24:17.020 --> 24:22.060 revamped the following infrastructure the past year. This year, the plan is to keep improving it, 24:22.060 --> 24:32.060 but also to improve the way we maintain the CIWOT's healthy. Relief, the WGP API, this time is for real. 24:32.940 --> 24:39.740 I think it's going to be in September. Android support, we will continue doing this. We will finish 24:39.740 --> 24:46.940 the migration to the new API, which is crucial to be able to use also 0.0 copy buffer sharing. 24:47.740 --> 24:51.420 And the idea is to integrate it also with the WGP testing infrastructure, let's see. 24:52.540 --> 24:57.580 And then for WebExR, we will continue there. So, this take into the last slide promise? 24:59.420 --> 25:03.980 So, the message I want to deliver here today. I know this is a very high level. It's not super 25:03.980 --> 25:11.580 technical, especially after all the talks here. I don't want to sell you anything, but 25:13.820 --> 25:17.980 the truth is that we are in a really good moment for WebExR. It hasn't been always like that, 25:18.540 --> 25:23.260 but we are now in a really good moment. We have a complete implementation with a web platform 25:23.260 --> 25:27.900 that you can use on GTK application super easy. On other applications, you can use WGP. 25:27.900 --> 25:33.020 WGP comes with back and so ready for well and DRM and headless, but nothing prevents you to 25:33.020 --> 25:37.580 create your RM backend. We actually created a GTK for backend, just as an experiment, 25:37.580 --> 25:43.180 so that you can actually use WGP now easily as well on GTK applications. 25:45.500 --> 25:49.820 If you pay attention to the history, you realize that those these ports are very much your 25:49.820 --> 25:55.900 very actively maintained. And the last 4 years were crucial, and now the next years are going to 25:55.900 --> 26:01.340 be the plan is to keep working around this line. So, we got to a great point now we want to keep 26:01.340 --> 26:06.300 improving, not just performance, but also we want to make sure that this is a great product. 26:07.340 --> 26:10.940 It's a great product now, but we want it to keep being a great product. So that's why we are going 26:10.940 --> 26:19.180 to put this year, especially on anything related to QI and maintenance. And yeah, pretty exciting, I guess. 26:20.140 --> 26:25.020 And yeah, and that's it, I think. I made it in 26. Sorry about that. 26:33.340 --> 26:38.540 All right, maybe we can do one question, because we don't have the thing. Patrick? 26:40.140 --> 26:44.540 My question is around the six-month release cadence. I was wondering whether you could say where 26:45.340 --> 26:52.780 these cadence was coming from. Yeah, that's a clear answer. So, WGDK has started as you saw with 26:52.780 --> 26:58.860 very tiny integrated with a non-project. And this basically aligns with the cadence of the releases 26:58.860 --> 27:03.580 of the non-project as well. So the idea is that more or less marked September, which is also when 27:03.580 --> 27:07.820 the non-cams with the releases, we also can with the WGDDK releases. So everything is aligned. 27:09.420 --> 27:12.540 Perfect. Thank you so much. It's been great. Thank you. 27:14.540 --> 27:16.540 Thank you.