[Webkit-unassigned] [Bug 283820] REGRESSION(286605 at main): [WPE] Massive performance regression on postercircle

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=283820

--- Comment #3 from Jani Hautakangas <jani at kodegood.com> ---
I'm able to reproduce this on rpi3. The problem is less noticeable in desktop environments due to their better processing power.

The issue isn't with the calculations or even the new preserve3d logic, but rather with how TextureMapper renders intermediate surfaces. Currently, TextureMapper attempts to minimize the size of intermediate surfaces by considering clip regions and only rendering overlapping parts necessary for the surface. This logic dates back to 2013 (see https://bugs.webkit.org/show_bug.cgi?id=110762). However, with modern hardware and use cases, this optimization may now cause more harm than good in terms of performance.

TextureMapper doesn’t cache intermediate surfaces during a single paint call. Instead, it renders regions on demand, often causing the same content to be rendered multiple times into slightly different-sized intermediate surfaces. This behavior is particularly problematic for translucent layers, such as the poster circle, which require intermediate surfaces. When these layers are clipped, multiple small intermediate surfaces are created, leading to reduced performance.

This issue is not limited to the poster circle—it also affects other scenarios where layers requiring intermediate surfaces are rendered multiple times, such as backdrops and replicas.

The solution is to pre-render the full layer’s intermediate surface at the start of the paint call. This pre-rendered surface can be reused multiple times within the same paint call for rendering masked splits from that layer and released at the end of the paint call.

This logic is already implemented for flattened layer surfaces and can be extended to more general use cases. In fact, this approach was discussed during the implementation of the new preserve3d logic, but I haven’t yet had the opportunity to implement it.

I'll start working on this

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20241130/f90f2c12/attachment.htm>