 So, as I said, my name is Emil from Collabora and I'm going to talk about WAFOS. So, first, here is a bit of contents of what I'll be doing talking about today. I'm going to give you a brief introduction of what WAFOS is, why it came to be some introduction of the API, references, an example, build system, GitLab, and so on. Bear with me just one second. So, I got some time on roughly. So, WAFOS. Project has been started quite a few years ago, 2012, by Chad. As he described, it's a library for selecting the OpenGL or GIS API and the windowing system at runtime. Pretty sure all of you are familiar, but just as a very, very quick introduction, the windowing system is the APIs used to integrate your, let's say, your Windows native calls with the rendering APIs of GIS. On top of that, you have various combinations and permutations, which I will mention shortly. Development was inspired by Piglet. As of today, it supports quite a few windowing system APIs as listed there. We have CGL, which is the Cocoa or Apple GL. WGL, which is the Windows integration. GLX is the integration with X windowing system. I'm not sure how many of you know about this next one. It is the native client for the Chromium. On top of that, we have EGL with all the varying platforms we can see in there, Android, GBM, Surfaceless, Wayland, Text11. One of its goals would be extremely lightweight and simple. If you are using or you have used SDL, you've noticed that it does provide the same sort of abstraction, the same helper, but it provides a lot more as well. If you actually go through the code, you see that it's a lot more heavyweight since it creates multiple constex, sometimes it creates multiple windows beforehand just to understand what the system is. Personally, I've been involved since 2014 as GSOC. I implemented the Windows backend or WGL backend. Kind of shortlist there, but here you go. As far as I'm aware, there are at least three users of Wofo. First and foremost is Piglet, which is an open source testing suit for OpenGL drivers, which was then extended to cover OpenGOS and OpenGL. Started by Baskos with us over there. Oh my god, I need it up. Okay, there we go. First fail. Second one is API trace, which is a tool to capture Jailstream. It can also capture, there are three this stream. You can retrace, inspect, replay. Both of those projects are supported at least on Windows, Apple and Windows. Obviously, various BSDs are supported as far as I know, but to what extent I'm not familiar. On top of that, about 2012, the person behind Vande and Chad more or less deported the open source engine to Wofo as well. And here's an interesting quote they mentioned. Next, why? So as I said, it covers quite a bit. The platform specifics vary depending on how you look at the substantial amount of time. As far as I can say, it does make porting a little bit easier. Something a colleague of mine actually mentioned. There is the aspect of making the distribution and dependencies a bit simpler since if you use Wofo, you don't need to pull all of X or all of Wayland at the same time if you don't want or if you're not interested in one of those. And most importantly, as I said, it is easy in driver development and validation. As I mentioned, Piglet and API Trace, they can be run on multiple platforms. So one potential, not potential, it's actual practical use case is to actually capture a trace on, let's say, Windows and then replay it on Windows and vice versa to see and analyze if there are any particular differences. And there's another question, why? Perhaps OpenGL is quite an aging API and Volkan was introduced a couple of years ago and it's obviously lower overhead, more driver control, et cetera, et cetera. But there are two main reasons why, at least you would say, the main reasons why we want to have Wofo. One is some drivers just simply not kept, not available and secondly is some hardware is simply not capable of fulfilling the hardware requirements by Volkan. There's a very, very short snippet of the different APIs available. There's a very short snippet and why in practical terms we need it. So as we take a look from the mentioned previously, display creation and connection and context creation is reasonably straightforward with EGL but as soon as we get to actually creating the window, that varies a lot on the underlying platform under EGL. So for X, you can use the XCB API and call XCB create window or create window checked. On Wayland, you have to create the Wayland API on GBM. GBM API on Surfaceless, you have to create, use another API on Android and so on and so forth and that fairly quickly gets fairly, fairly messy. Additionally, one piece I didn't mention here is that during your creation, you have a particular set of tokens or flags on pretty much any Geo windowing API where you can specify, let's say the major version that you're interested in, the minor version of the Geo implementation that you're interested in, what you want to call, compatibility profile and other details which vary across. Another quick example is the GLX. As you can see, fairly similar. As you know, XCB can be used to manage the windows. We have a GLX explicit API for context creation but we don't have GLX API for connecting to the display so we have to use the X APIs. It gets even better with WGL where we will have platform-specific API for the window management. We will have a WGL API for context creation and we already don't have an API to create, connect to the display. We will have to do something else. Quite often you might be interested in getting the underlying details. Would that be the actual window? Would that be the Geo surface? Or would that be the actual Geo display? There are native get-native callbacks for pretty much everything. You can have context get-native and you can just get the information this way. A very, very quick example. Bear in mind that I haven't omitted any sort of error checking for brevity but normally you want that. You will specify a very short attribute list what kind of platform you want. You will initialize your connection. You will connect to the display. If, for example, you know a specific display, you can give the name of that display and it will try to connect to that. Then you will have a bit of attributes and here I've chosen a core profile, OpenGL profile, and a minimum version of 3.3 but on top of that you can provide other details such as I would like to have a RGB 888 or a different... One interesting topic that has come up a couple of times is why do we need to specify the platform? Surely you can add some characteristics and let Waffle detect that for you. The reason is that in this space Waffle aims to do the very little, the very base, the very minimum for you to just simply not bother with the platform specifics but at the same time a high level decision such as what you want to use that be X, Waylon or something else, it is a decision of the user so if you have a toolkit, I believe GTK these days will query for an X and a Waylon connection and it will attempt a Waylon connection first which has interesting implications such as quite often I wonder where everything has gone. So after we build up the state we obviously choose a configuration and based on that we can create our context. Then after the context we specify some window specifics in this case dimensions although you can say I want a full screw in the window and others, you create your window, you make it current and then you do your fancy drawing. If I'm not sure to what extent people here are happy or have used GLA, CGO and so on, I think all of you will agree that this is a lot shorter than a senior at least from my point of view it is. Okay, the original is CMake which is, this is a job, personally I'm not a huge fan but that's my own view. On top of that we have an Android build system because building the Android back end requires some low level specifics which are not available in the SDK. Yet to investigate if and to what extent we can remove those cleaner syntax perhaps some will disagree but that's how I see it. Additionally it has fairly active community and they are quite proactive in improving and not only usability but also handling of tooling. So for example if you want to build to the various analyzers, address sanitizer and so on, there are handy shortcuts for that. Next thing is GitLab. We have talked quite a bit, well not quite a bit but all of the developers have agreed that moving the current hosting from GitLab to GitLab instances is a wise move. Unfortunately we haven't had official timestamps because the original author was away for personal reasons as far as I'm aware. Although as I said everyone is in favor and we just need to make it official and do that. Sort of a sales pitch but not really. From my point of view GitLab is obviously a bit trendy a bit better because it's fully open source software. Integration with CI tooling and CI additional tooling from my point of view seems a lot easier, a lot thinner, you don't need multiple accounts, you don't need multiple integrations and so on. I've played around with GitLab pages and I've played around with GitLab pages. Again, personal views, the GitLab ones are a little bit easier to manage. Yet it doesn't really provide a simple querty scan integration which considering querty wasn't accessible recently, I'm not sure if it's a major downside. The other part is it doesn't really have an easy access for proprietary platforms like Windows or MacOS. We should be able to wire up the Android integration but not for those who actually need to have a local runner unless something else comes out, of course. Another thing that I was wondering is perhaps we can use the GitLab as an actual mirror and base those two off there. A bit about the work ahead. As I said, we really should formalize the transition to GitLab, put official stamp and get it working. I believe we need to improve the documentation in particular how do we handle merge requests, how do we handle reviewing, how do we handle releasing because there's every open source project, those are places that do require a bit of polish. I haven't actually covered that but I'll get into it now. Originally, Patch submission was handled through merge. As I mentioned earlier, looking to improving the Android integration making that a lot faster and out thinner, polish the CI, add a bunch of pipelines, perhaps less, perhaps more, and... How big is the size of the code? With the tests, around 16K. Without the tests, around 800 with all the boiler plates per platform. So we have like nine niche platforms around, I don't know what's the number is. I said around 800 but that's a bit of boiler plate as well. Do you understand this is sort of provisioning? Any measurement performance impact? Didn't bother to be honest because I'm not really possible to show you but the only time implication that you might have is during the selection process. So when you have a list of attributes, as I said, you have like a window with certain dimensions. The only time taken is literally just to process that list. When you create the window, it literally just goes on windows, create window. That's it, nothing else. How do you handle the events in each environment? In the next, you have the way to handle the events in the way that you have the input. So if you want to handle events, that's one of the reasons why the native window is provided. So you can wire that with whichever input handling you prefer. Waffle is mostly aimed and concerned about abstracting the rendering specifics, yes. Or the window system is specific. Yes? What will be the new platform? Does the application need to be rebuilt in order to support that? Can you repeat that, please? If Waffle has support for a new windowing system, does the application that using Waffle then need to be rebuilt or is it just enough to rebuild Waffle? Depends on exactly how the application is using Waffle. So if the application has, let's say, a user token, which then gets fed into Waffle, there should be no need whatsoever. One of the pieces I've been working on is to effectively expunge all the dependencies, all the static linking from Waffle. So the only thing that you depend is literally just lib tl, lib c, and lib ptrails, I believe. So as I said, you just have it there whenever it's updated as a new platform, your users can just flip the token and try the new platform. Anyone else? Yes? That's an interesting question. So originally, Waffle was aimed to handle dispatching as well. The person behind lib epochs, he believed it's better to spin it to another project, so he did that. At the moment, I'm not seeing a particular reason to integrate these two projects, because if anyone wants to, they're more than welcome to. Both of the projects are really nice because they provide you a fairly distant API so you don't need to worry about those specifics. But I don't see a particular reason to integrate those in one shape or form with one another, that is. Anyone? Are you seeing much interest in getting this adopted in various projects? It would be nice for end users if various games work on more platforms, but obviously that depends on games using it, or maybe they use SDL. Is that gonna pick it up? So as far as I'm aware from serious game development, they are mostly focused at SDL because it provides a lot more. As I was asked here, it handles input, it handles a lot of other things, and developers don't need to care. Wafua hasn't seen much adoption from my point of view, is because, first, it lacks input, and secondly, we don't cater that much to providing high-level decisions, like as I said, the automatic dictation, which is perhaps what some users want, which might be a deterrent. Anyone else? I have one more question. Yeah, go on, please. So with regards to the Wayland context, recently we had to add some color conversion to be done in the shader, in GLS shader because it wasn't supported, and we had some graphics that were in particular color command, YUV variant. Would we have to do the same thing from the start, right, in Wafua? Would you provide some... So essentially we had to do that in Wafua. Which... So technically... It has to be done also for Wafua, right? I don't think so at the top of my head, to be honest, but I need to double-check. Eight years ago I was looking into Wafua, and technically it should be possible for Wafua to use Wafua, let's call it this way. If there's any idea what other people will agree, that's always another. As I said, I need to take a look into the details and come to an answer like that. Anyone else? Well, thank you very much then.