RESOLVED WONTFIX 218278
[GTK][WPE] Enable direct compositing of images with rounded corners
https://bugs.webkit.org/show_bug.cgi?id=218278
Summary [GTK][WPE] Enable direct compositing of images with rounded corners
Miguel Gomez
Reported 2020-10-28 03:45:44 PDT
Now that TextureMapperGL can perform rounded rectangle clips, we can enable the direct composition of images that have rounded corners. 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.
Attachments
Miguel Gomez
Comment 1 2020-10-28 09:06:31 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.
Miguel Gomez
Comment 2 2020-11-10 05:10:58 PST
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.
Note You need to log in before you can comment on or make changes to this bug.