Skip to content

WPE WebKit Web Engines Hackfest 2021

Jump to bottom Edit New page
Manuel Rego Casasnovas edited this page May 12, 2021 · 2 revisions

WPE WebKit - Web Engines Hackfest 2021

Agenda

Time (UTC) Topic Description
16:00 State of the Union Review WPE status & Technical Roadmap 2021
16:45 Test Automation and WebDriver Review of latest achievements regarding functional testing within WPE (Selenium and WebDriver)
17:00 Quality Assurance What are we doing regarding test coverage, continuous integration and metrics
17:30 Break
17:45 Embedded Running WPE in embedded architectures with a focus on tooling, use cases and real-world scenarios
18:15 Graphics Discussion about the new graphics pipeline (libyaa, Nicosia), new graphics proposals (Skia) and HW accelerated SVG renderization
18:45 Conclusions Discussion of other topics, summary & conclussions

State of the Union Review WPE status & Technical Roadmap 2021

Start: 16:00 UTC

(presentation by Alejandro García)

Diego Pino adds a few comments on QA:

  • The non-unified builder EWS bot is deployed in an environment for testing bots but not publicly visible. Aakash (Apple) suggested to have also a post-commit bot before as well. Discussion ongoing in the mailing list.
  • Bots have been using Flatpak for ~1 year, but the JHBuild support is not going to be removed soon because it seems that is still useful for a few many people. For example the JHBuild is still useful for people with Nvidia drivers: https://bugs.webkit.org/show_bug.cgi?id=219456

Chris Lord talks about the security bot plans, he wonders if we have a plan for filing and handling issues e.g. from TSAN builds. Lauro Moura answers that the runners for the sanitizers are running but still being tested; Diego adds that one remaining issue is that debug builds might be needed and those are huge. Lauro comments that currently is not a problem because the bots right now are on the same premises so there is no need to upload the build artifacts to California and download them back for testing, but there may be some work to do there still. Regarding how to handle security issues, Lauro thinks that issues found by the bots should follow the usual procedure for security issues, which coincidentally is what also happens e.g. for bugs found by Apple's fuzzing bots.

Diego thinks that the HTTP/2 support is partly already upstream, asks for clarification. Patrick answers that in about two weeks it should be possible to have the first builds with it—hopefully on time for the next development release but disabled by default.

Alex asks what's the status and plan for the Cog user interface, and how it's going to be implemented. Adrián Pérez replies that he has been doing a few experiments, and the idea at the moment is to use Flex (single file C library which implements Flexbox, made for Xamarin Forms) for layout and Cairo for rendering the UI elements (because it is not performance critical, won't update too often), and that way the renderer browser chrome can be painted onto a graphics buffer. This will allow integrating the same UI code with all the different Cog platform plug-ins (Wayland, DRM, X11, etc.), because all of them have some way of putting a buffer on screen; some platform plug-ins may even use ways of doing this without affecting at all the way in which rendered web content frames coming from WPE WebKit (for example, using a subsurface in Wayland), though in some cases it may be needed to use OpenGL ES to sample both the web content frames and overlay the UI on top. Nevertheless, the support for the UI chrome will be selectable at runtime to keep supporting kiosk-like use cases and avoid doing additional work when it's disabled.

Alex asks Nikolas Zimmermann about the SVG render work. Nikolas replies that it's mostly ready from the testing point of view, with a single layout test that is still failing but he is confident that he can get it axed in a week or so. There has been some discussions with people from Apple which resulted in rearchiteturing of the patch set, making it better and solving a few secondary issues along the way.

Test Automation and WebDriver Review of latest achievements regarding functional testing within WPE (Selenium and WebDriver)

Start: 16:45 UTC

(presentation by Lauro Moura)

Diego Pino asks what's the level of support for WebDriver on other ports, as it looks like we are the only ones running WPT. Lauro replies that this is testing depends on the browser and due to that Apple needs to use Safari. We support some tests on MiniBrowser and some on Cog, it is enabled for each browser individually.

Carlos Garcia clarifies that WebDriver has two parts: the driver part which is not inside the WebKit tree for Apple ports, which is the reason why they don't run the tests in the public bots. It usually takes more time for Apple to find bugs because in our case when we do changes the bots automatically test it, but for SafariDriver it's not always the code from trunk so they find issues when it gets updated.

Pablo Saavedra asks what's being used for running WebDriver tests, as there is no support for that in Cog. Lauro replies that MiniBrowser can be used, and during the preparations for the today's talk he implemented support in Cog for WebDriver, but some things do not yet quite work e.g. support for multiple web views is needed.

Quality Assurance What are we doing regarding test coverage, continuous integration and metrics

Start: 17:00 UTC

(presentation by Lauro Moura)

Break (17:30 UTC)

Embedded Running WPE in embedded architectures with a focus on tooling, use cases and real-world scenarios

Start: 17:45 UTC

(presentation by Pablo Saavedra)

Diego asks about the most recommended way to go today for somebody wanting to build WPE for the Raspberry Pi.

Pablo explains that it depends on what's your purpose and needs. The fastest/easiest way is probably Buildroot, and it's the recommended way if you only want to quickly hack on WPE or its libraries. This presentation explains Yocto because it's the de-facto standard for big companies to build images for embedded devices.

Adrián comments that the Buildroot WPE packages are still pending to be updated to the latest version. There's no predefined configuration or good instructions yet that explain how to build WPE on Buildroot—we should probably write this down somewhere. On the other hand, Metrological has a somewhat outdated downstream Buildroot fork that is actually useful if one wants to build their downstream fork of WPE; but otherwise it is strongly recommended to use official upstream Buildroot releases, where the most up to date build recipes are maintained.

Graphics Discussion about the new graphics pipeline (libyaa, Nicosia), new graphics proposals (Skia) and HW accelerated SVG renderization

Start: 18:15 UTC

(presentation by Chris Lord)

Daniel Kolesa is wary of seeing Skia around because it is painful to work with (e.g. no releases) and it's optimized only for Clang, and also very centered around what Chromium needs so for example does bit-fiddling which is dependent on x86/ARM and is hard or near impossible to get upstream to accept patches.

Chris Lord explains that in initial meetings nobody was too keen about Skia, but Cairo remains unmaintained and is problematic because of that. Hopefully the new pipeline would make Skia a non-option. Besides releases it's also hard to upstream changes. Benefit of Cairo is that it's practically finished i.e. doesn't change.

Daniel Stone does highlight that Cairo is being lightly maintained again, but time needs to undo all the bad rep that Cairo has accumulated over the last years. Also Cairo GPU backends are very poor and not an ideal solution.

Daniel Kolesa asks about a Cairo2. Daniel Stone explains that Cairo is at least predictable, and changing that could be problematic, and would need a lot more effort than what the current light maintenance requires.

Adrián comments that he has noticed in the GTK development channel about some effort to remove cruft and old code from Cairo, because the GTK developers seem interested in having at least the parts of Cairo that are actively used and known to work well better maintained. Does this relate to the new maintainership of Cairo we are talking about?

Daniel Stone explains the current maintainer does a very basic maintenance job, there's no huge effort to unbreak the complexity that lead to the unmaintainability. Approaching the maintainer and having these discussions could evolve somewhere in that direction. Test suite is a large piece that needs a lot of attention, 50% passing rate would need to be improved.

Chris Lord is glad to hear about the renewed Cairo activity, assesses Skia transition would be a huge effort in itself. Believes the new graphics pipeline, if it goes as well as hoped, would be a better long-term solution. We may still need something like Cairo for printing, but while it is unclear at the moment how printing will be handled keeping Cairo for that may be an option.

Daniel Kolesa mentions similar conundrum inside Firefox. Chris Lord explains they first transitioned to Skia but that are now moving over to WebRender. Daniel Kolesa believes the transition is not yet complete, and Chris Lord agrees they might be still using Skia in different places along with WebRender.

Daniel Stone asks about WebGPU, WGSL, whether there's work around it.

Žan Doberšek replies that the issue with WebGPU is that there is some friction between Apple (who initially proposed the standard) and Google (currently implementing it inside ANGLE). An option might be to leverage ANGLE's implementation as we do today for WebGL but needs to be investigated thoroughly. When we looked at it a while ago it seemed like it was a prerequisite to have Vulkan underneath, so if that is still the case we would need to either have WebGPU isolated and its results being usable in our GLES based pipeline, or making our pipeline have the possibility of running on Vulkan.

Daniel Stone comments that there has been work from Eleni Stea allowing interop between Vulkan and GL context by implementing suitable extensions to allow this.

Žan adds that we are aware of the interop, and that there are also other considerations like inter-process communication as WebGPU would run in a separate process. There are ways to go about this that we will have to look into. As part of the graphics pipeline rework there is also rearchitecturing work which we expect will take into account all this.

Kris Konopko wonders if the fallback cases in which software renderer may be needed (e.g. printing, or when GPU is not available) need also solving the Cairo vs. Skia dilemma.

Chris Lord thinks the pipeline could be run on software rasterization, but the results could be not that great. If/When moving over to the new pipeline, transitioning to Skia in parallel could be more effort than it's worth.

Conclusions Discussion of other topics, summary & conclussions

Start: 18:50 UTC

Chris asks about EWSs, whether the GTK instances could be running tests as well (much like Apple instances). Chris wonders about the status.

Diego explains this is ongoing work. Prerequisite is that the main bots are green, so that EWSs are not red for invalid reasons. We now have more hardware. An issue in one bot are early exists due to large amount of test failures that are actually flaky tests. Diego suspects some systematic error on that device since tests don't work there. But the tests have to be kept green, and EWSs will not reflect the actual state of the target patches, and Aakash would not appreciate having to handle results from such EWS instances.

Carlos Lopez agrees, flakies being the main problem. He isn't sure whether it's the system's problem, but the bot will be set up from scratch. An alternative is to convince Aakash to allow our EWSs to run with more allowed failures, so that we still catch the most patches.

Kris asks about TLS status, GnuTLS is used to provide this. Will there be more flexibility around how this can be programmed? Second question, will this be used to support TLS Session Tickets?

Carlos Garcia answers that glib-networking provides API for the client-side certificates, there's different callbacks that can be used (for certificates and for PIN values). API will be added to libsoup to expose callbacks on a per-message basis. It will be used inside WebKit to support authentication interactions.

https://www.webengineshackfest.org/

Add a custom sidebar
Clone this wiki locally