2024 WebKit and Skia

WEH 2024 - WebKit and Skia

• GitHub issue: https://github.com/Igalia/webengineshackfest/issues/36

Notes

Carlos García presents, explaining the motivation and how the Skia integration effort started.

TL;DR: There's a few known regressions and issues with Skia but in general works better than Cairo already, and it's expected that the next stable release series (2.46.x) will have Skia enabled by default at build time, with Cairo still as a fallback build option. Future work will revolve around making the compositing architecture more suitble for GPU rendering.

Martin Robinson: Skia has configurable rendering backends, I wonder if there's any thoughts about when to use CPU vs. GPU backends depending on different rendering situations.

• Carlos: By default we are using GPU rendering, but on some embedded systems we still have to use the CPU and we use the same threaded rendering we had with Cairo but using Skia display lists. The improvements in the graphics architecture planned for the future are intended to be able to use GPU rendering in such devices. Right now it's also possible to use CPU rendering for everything and GPU for accelerated canvas (same as before when we had Cairo-GL support for canvas). In the future another advantage of using Skia is that there is a new backend called Graphite that we might want to use for non-GL drivers (Vulkan/Metal).
• Adrian Perez: Adds that for canvases that have the “read frequently” hint the rendering will use CPU to avoid downloading pixel data back from the GPU, and that there are heuristics that can decide to render small tiles/canvases using CPU because below certain sizes the additinoal setup work for GPU rendering does not pay off.

Ian Grunert asks in the chat about Big Engian (BE) support in Skia:

• Carlos: We are aware of the lack of BE suport
• Daniel Kolesa: Has a couple of BE machines at home and thinks that technically is not that much of a problem to support BE, the question is mainly what to do with the BE support going forward once implemented.
• Carlos: Is that worth it?
• Daniel: I think it is, as it improves the code quality in general.
• Nikolas: How about testing infrastructure for BE Skia?
• Daniel: ?? and issues are relatively minor when disabling the accelerated canvas, even today with Cairo things tend to work. I have the hardware, other people do as well, and there are communities of people who can provide feedback so I don't think we need to concern ourselves much with that. Mainly we shold worry about upstreaming the patches.
• Nikolas: Follow-up question, how much effort has it been to keep BE support working?
• Daniel: Nothing is needed these days to build WebKit on BE PowerPC, no idea about other BE architectures but probably not much of an issue. BE ARM is doable and some RaspberryPi models can be configured on BE mode. PowerPC is probably the easiest to get hold of. Most of the fixes over time have been related to JavaScriptCore; most of the fixes are trivial. There are some graphics glitches which one does not tend to find and are minor, for some I have patches which I am not completely happy with and need some touching up before upstreaming. In general WebKit is doing the right things with regard to BE architectures. There are people maintaining odd patches for TypedArrays that expose their contents as LE to websites even when running on BE architectures to get websites going, but in reality it's a gross hack that has downsides and ideally websites should be fixed instead. It would be nice to have JSC with JIT on BE, but nevertheless even without it JSC is the fastest engine in PowerPC at the moment.
• Alex: We have always been open to supporting this kind of thing (niche architectures, systems) and if the situation is as you mention, we are fine with that. I was talking with Mozilla folks and they don't even have the BE/s39x patches in the repository; it's something that distributions apply locally.
• Daniel: once we tried to upstream PPC64 LE support in Chromium at some point and even with IBM vouching for the changes it was not possible. We have not tried upstreaming to Skia given the experience with Chromium.
• Alex: I think there's two options, and we are not going to be able to maintain Cairo forever in the WebKit tree, so the options are upstreaming to Skia, or to have distributions pick the needed patches.
• Daniel: If we could build Skia seperately this wouldn't be a concern.
• Alex: That's not an option, it's trying to go for more work than trying to contribute to Skia.
• Adrian: We can (and had at some point) small local changes to Skia inside the copy we carry in the WebKit source tree, but it has always been with the intention of upstreaming them (which we have been doing) to be able to update our copy of Skia often (ideally every week; but we've been doing every 2-to-4 weeks). We have added support for Epoxy in upstream Skia, which is something Google does not have testing infrstructure for, so they can break it at any time and it's our responsiblity to keep working. We might be able to make BE support happen in a similar fashion. The Skia team has been more receptive to outside patches than other Google projects.
• Daniel: It's probably best to test and fix Skia standalone on BE by itself, because we know that WebKit is sound in this regard so it's more likely that the issues come from Skia itself.
• Alex: We cannot make promises about for how long we can maintain Cairo support in WebKit.

Ian Grunert asks in the Jitsi chat about improvements in Skia for Speed-o-meter:

• Carlos: cannot say because we have been focusing on MotionMark first.
• Adrian: I have tried Speed-o-meter a few times, comparing Cairo vs. Skia, but can't remember about particular numbers because last time it was over a month ago; nevertheless I can say that the results were better than with Cairo, although not as spectacular as for MotionMark because Speed-o-meter also measures DOM operations and JS APIs for it.

Philippe asks about whether Cairo would still be used for printing as Firefox does, or Skia.

• Carlos: We already use SkPDF on main as of now, but only PDF output is supported.
• Georges: Something we don't have is printing to SVG, althought Skia has some experimental support for that, so we have to disable producing SVG and PostScript printing output support. There are some small differences in the produced outputs compared to Cairo but it's not something very noticeable.
• Alex: I would support fixing the issues we have with Skia and printing going forward, instead of using Cairo only for printing, this makes more sense for us.
• Carlos: I know that Cairo has excellent PDF output support, but agreed that it's likely better for us to use Skia.
• Alex: Maybe part of the reason Firefox is still using Cairo for printing is to avoid any kind of regression, maybe they can't afford them; but we should be in a better position and use Skia even if our output changes slightly compared to the Cairo PDF output.
• Georges: Printing these days mostly goes through PDF, and even for slightly older printers that may not support PDF directly conversion is done by the printing server/system from PDF to what the printer consumes. Regarding how the PDFs are generated, when writing PDF there is a kind of “DOM” for the document and Skia and Cairo may be using slightly different constructs and the visual output should be the same or almost the same which should be fine.
• Georges: There aren't two browsers that would print the same, so even Firefox with Cairo will not print the same as WebKit with Cairo, so it should not be a big deal that WebKit with Cairo prints something slightly different than WebKit with Skia.
• Carlos: Long time ago even with Cairo we were generating huge PDF files that many printers were not able to consume because they didn't have enough memory, e.g. the same image repeated multiple times would generate copies of the image so an API was added to Cairo to allow generating references instead of copies. I don't know if we are having such issues or even using the Skia PDF API in the best possible ways so there's still things to check there, for now we have an initial support which seems to work in many cases. Nevertheless printing has not been considered the most important feature of the web engine so work on this area has had less priority. WPE does not even support printing. We'll keep improving it in the future.

Ian Grunert asks in the chat what's the plans for e.g. display lists and making teh composition/rendering architecture more amenable to GPUs? What about funding for future work? Do we need many small buffers?

• Nikolas: The DisplayList architecture is very helpful in implementing the GPUProcess (and potentially rework compositing at some point). DisplayLists can be recorded e.g. in WebProcess, serialized and sent via IPC to GPUProcess/UIProcess for actual rendering. We already use DisplayLists for threaded CPU rendering, and it has proven to work well. In future, we might want to consider using it more extensively, in favour of buffer sharing, as it also unlocks many other new possibilities, e.g. to rework compsorting.
• Nikolas: Right now we have buffers for video content and other bigger buffers, but also have to deal with many small-ish textures for tiles coming from the compositor, which is not very friendly to embedded GPUs for example. We need to look at the whole pipeline to se where to improve and this is definitely one of the next steps we want to take.