| Summary: | [GTK][WPE] Enable direct compositing of images with rounded corners | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Miguel Gomez <magomez> |
| Component: | WebKitGTK | Assignee: | Nobody <webkit-unassigned> |
| Status: | RESOLVED WONTFIX | ||
| Severity: | Normal | CC: | bugs-noreply, Hironori.Fujii |
| Priority: | P2 | ||
| Version: | WebKit Nightly Build | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
|
Description
Miguel Gomez
2020-10-28 03:45:44 PDT
> This was disabled in r219445 for GTK and WPE platforms. In order to enable > it again we need to undo that change, and also check whether the image has > an invertible transformation matrix, as we require that to perform the > rounded clipping. This is getting more complicated than I expected. I wanted to use this call https://github.com/WebKit/webkit/blob/3420a35c9d08fb5d981c075d555754409ae1891e/Source/WebCore/rendering/RenderLayerBacking.cpp#L2817 to calculate inside the CoordinatedGraphicsLayer whether the transformation matrix is invertible. But the problem is that at the moment that call is performed, the CoordinatedGraphicsLayer only has its local transform set, not the accumulated transform combined with the ancestors. That has to be calculated recursively for all the ancestors, and that doesn't happen until the first layer flush. I've been thinking about this for a while and I think we should not enable this optimization. There are 2 main reasons for this: 1 - The advantage of this optimization is that we could directly send the images to the compositor to be uploaded as textures and be painted without having to render the image with cairo first. The reality is that, even enabling it, the image is painted into a buffer with cairo anyway, and that buffer is the one being passed to the compositor. So there's no gain anyway. To get some improvement we should send the image directly to the compositor as well, but that means problems with the threads and the image reference. 2 - As mentioned before, at the moment when we have to decide whether the optimization can be used, the global transformation matrix of the layer is not calculated. We would need to recursively calculate it at that point to check whether it's invertible so the clip can be done. This is doable, but the transformation matrix can change after that (animations), so there could be a situation where the matrix is not invertible anymore and the clip stops working. So we can't decide beforehand whether the clip is going to work for all the cases, which IMO makes this unusable. So, at least for the moment, I'll close this bug. |