240865 2022-05-24 04:23:00 -0700 [GTK] Webpages completely slow down when CSS blur filter is in use 2024-05-14 21:25:26 -0700 1 1 1 Unclassified WebKit WebKitGTK WebKit Nightly Build PC Linux NEW Gtk P3 Normal --- 245783 1 caden webkit-unassigned adam.gamble bugs-noreply cgarcia fujii kdwkleung magomez mcatanzaro nekohayo zdobersek oldest_to_newest 1871454 0 caden 2022-05-24 04:23:00 -0700 In recent WebkitGTK versions, when encountering an image with the CSS property filter: blur *px; the webpage performance can drop to over ten seconds per frame, essentially making the page unusable. This could have something to do with my high DPI monitor, but regardless, this is on a fairly high end PC with Ryzen 7 and dedicated GPU. This issue can be observed on Reddit when a post marked as "Spoiler" appears. The element takes an image and blurs it with a value of 60px, which brings the browser to its knees. Browser: GNOME Web v42.2 (and earlier versions) System: AMD Ryzen 7 CPU AMD RX 5700 XT GPU GNOME on Wayland (also happens on X11) 1871455 1 caden 2022-05-24 04:25:44 -0700 I should also note, after the element has been loaded for a very long time, it may begin to run smoothly again. However, resizing the element or the window will result in the page slowing down again. 1871459 2 mcatanzaro 2022-05-24 05:00:08 -0700 Pretty sure somebody else reported this on a different bug, though I can't immediately find it. At least you're not alone.... 1902015 3 cgarcia 2022-09-29 05:07:08 -0700 It seems the blur filter done by the cpu is slow. We might try to ensure it's always done by the GPU, but unfortunately it doesn't seem to work properly. Mac uses the accelerate library that I guess makes it a lot faster. I'll submit a test case. 1902016 4 462701 cgarcia 2022-09-29 05:11:31 -0700 Created attachment 462701 Test case There are two files in the tarball: - test-cpu.html: it has several images with blur filter. It's slow, it's easier to reproduce by resizing the window rather than just scrolling. - test-gpu: it's the same but adding a translateZ transform to force the images to be accelerated. Performance is much better, but there are two issues: + Rendering is ot the same as the sofotware version, it looks like pixelated. + Images disappear when scrolling and they aren't rendered anymore even if the window is resized. 1902174 5 fujii 2022-09-29 14:09:45 -0700 The pixelated issue is tracked by bug#231653. 1960997 6 magomez 2023-06-12 01:54:31 -0700 I've been giving a look for a while to how the blur filter works with opengl, but I need to change to another task, so I'll do a brain dump here of the things that I found out to catch up when I have more time. The blur filter is applied as an weighted average of the values of the pixels around the target pixel. These weights are calculated as from a gaussian distribution, so the weight is smaller as they get further from the target pixel. The filter radius specifies how many pixels to the lest/right/above/below are taken into account for the calculation. Instead of accessing all the pixel values that would be needed for each pixel, it's common that this is implemented as a 2 pass rendering, where during the first pass only the horizontal pixels are taken into account, and then during the second pass only the vertical pixels are taken into account. The combination of these two passes produces the same result with less accesses to the pixels, which improves the performance. This is what the TextureMapper implementation does. Then, regarding the specific implementation details: - TextureMapperGL is the one creating the gauss values and passing them to the TextureMapperShaderProgram in prepareFilterProgram. - In theory, we should be sampling as many pixels in each direction as the radius, but we're not doing so. We are always sampling 10 pixels in each direction (defined in GaussianKernelHalfWidth, which is 11 but it includes the target pixel, so it means 10 really). This means that we sample 10 pixels, the original pixel and then another 10 pixels, and this happens in both passes, so it's done horizontally and vertically. - If the radius is somewhat close to those 10 pixels, the result is going to be quite similar to the cairo implementation. But as the radius gets bigger and bigger, the result gets more different and the pixelated effect starts to show. This happens because as the radius grow, those 10 pixels that we sample get more and more separated among themselves, so we are sampling pixels that are not that close or related to the original pixel, so their contents are not related. Example to show the effect: 20x20 image, getting the result for pixel (10,10) by sampling 3 pixels (one to the left and one to the right, instead of the ten that we have in the real implementation). The gauss weights are (0.25, 0.5, 0.25). Talking only about the horizontal pass, but the vertical one has the same problem. - if the radius is one, we're sampling pixels (9,10), (10,10) and (11,10) with the assigned weights, which is perfect, as we're averaging the value of nearby pixels. - if the radius grows to 5, then we are sampling pixels (5,10), (10,10) and (15,10). But those pixels are not that close to the target pixel, so their content is not that related to it, and they will corrupt the result. Keep in mind that in the normal case, the second biggest weight is used for the pixels that are besides the target one, and in this case it's applied to a pixel far from the target one. The test attached by Carlos uses a radius of 60px. This means that we're sampling 10 pixels to each side, one every (60 pixels / 10 samples) 6 pixels, which shows the strange pixelated effect. As the radius gets reduced, the result gets closer and closed to the cairo one, because the pixels sampled get closer and closer to the nearby ones. There's also a detail in the implementation that I think it's a bug, and it's definition of GaussianKernelStep to 0.2. This defines the advance for each sample. If we're using 10 samples in each direction it should be 0.1, as the position gets calculated as i*step*radius (i=1..10). But being it 0.2, this means that we're sampling up to the double of the radius, which makes the result even worse. So, after all this mess, what's the proper fix to this? - First would be changing that GaussianKernelStep from 0.2 to 0.1. That will keep the result fine for bigger radius. - Eventually the radius will get big enough to cause the buggy rendering. There are several options here: * Increase the number of samples to match the radius. This would produce the perfect result always, but the computational cost will grow a lot as the radius grows. * Increase the number of samples from the current 10 to something bigger, like 30. This would make the result fine fine for bigger radius values, but there will be a point where the result will get buggy anyway. * I saw that some implementations use a trick here. Taking advantage of the interpolation done by opengl when copying textures to different sizes, what they do is they reduce the size of the image to filter and the radius to match the number of pixels that we're sampling. So if the image is 100x100 and we want to use a radius of 40, that's the same than sampling and image of 50x50 with a radius of 20, and the same as an image of 25x25 with a radius of 10, that we can do with our current 10 samples!. I think this is the way to go, despite it requires some not so obvious changes to TextureMapperLayer to perform this downscaling. 1960998 7 magomez 2023-06-12 01:56:56 -0700 > - In theory, we should be sampling as many pixels in each direction as the > radius, but we're not doing so. We are always sampling 10 pixels in each > direction (defined in GaussianKernelHalfWidth, which is 11 but it includes > the target pixel, so it means 10 really). This means that we sample 10 > pixels, the original pixel and then another 10 pixels, and this happens in > both passes, so it's done horizontally and vertically. I mean 10 pixels to each side of the target pixel. So 10 to the left and 10 to the right. 1976041 8 kdwkleung 2023-09-06 21:05:13 -0700 Pixelated issue seems to be solved by a PR. Would it be possible to use GPU for blur now? 1976044 9 fujii 2023-09-06 21:39:59 -0700 Yes. bug#231653 is fixed. But, you have to add a CSS property will-change:transform or transform:translateZ(0) to a element to composite with GPU. 1976045 10 kdwkleung 2023-09-06 21:42:09 -0700 (In reply to Carlos Garcia Campos from comment #3) > It seems the blur filter done by the cpu is slow. We might try to ensure > it's always done by the GPU, but unfortunately it doesn't seem to work > properly. Mac uses the accelerate library that I guess makes it a lot > faster. I'll submit a test case. I was referring to this comment. It would be great if the GPU can handle all blurs so as to take the load off the CPU entirely, and greatly improve performance. 1976615 11 mcatanzaro 2023-09-09 07:01:28 -0700 I see a number of related fixes in bug #261022, bug #261101, bug #261187, and bug #261102. These are all present in 2.41.92. Please check and see if the problem is resolved. 1976616 12 mcatanzaro 2023-09-09 07:03:50 -0700 (In reply to Carlos Garcia Campos from comment #4) > Created attachment 462701 [details] > Test case > > There are two files in the tarball: > > - test-cpu.html: it has several images with blur filter. It's slow, it's > easier to reproduce by resizing the window rather than just scrolling. > > - test-gpu: it's the same but adding a translateZ transform to force the > images to be accelerated. Performance is much better, but there are two > issues: > + Rendering is ot the same as the sofotware version, it looks like > pixelated. > + Images disappear when scrolling and they aren't rendered anymore even if > the window is resized. I tried these test files with 2.41.92 (but not 2.41.91, so I don't know how bad it was before). I didn't notice any performance problems with either test. But with the test-gpu, I noticed that rendering breaks after I scroll down and then scroll back up. The web content becomes all white. Should I report a new bug for this? 2035455 13 kdwkleung 2024-05-14 21:25:26 -0700 This should be fixed with Skia 462701 2022-09-29 05:11:31 -0700 2022-09-29 05:11:31 -0700 Test case blur-filter.tar.bz2 application/x-bzip 4350 cgarcia QlpoOTFBWSZTWb4Ga1MABb1/////////////////////////////////////////////4Au/fAH3 ztrvefWT2+3OcXffV8o6A3vpnutd8upXvd71Z69DUKNCaZMptMU9TepqmMjKbFPEyjwU8k9Nqnqe p6aNI/U2imaaGUeppmiabU2p6T1PKepp4jKbJlNNpPU/VNomngo8p6ZBlHqbU9NTwSGynqMMmJqH qbak9MUwEyPSPUIpoTRPRMU3qamRmobSep6hkNNMIwhpoBoxMah6Mp4oZNkTZTTBqbUaDGkBtQZA AaBoNBoaZAAANGhoGRoA0DEDQ0aaERICTwj1T0yankaNTZGINTyT00niRtTJhNGmIxHqaZGhoaaM TQaaAGgAGmjTT1ADRoaMmgwgGgHqMgeoANA0AGQNAAahJpk0p+RPU0NDSbQg0xNDJkaDQ0yaNGmQ MgZNGgAZDQMjQADT1AGg00aaAANGgGg0AA0AAAAAANNADTRIRDFT1P1NMSfqn4go21TT2kmntU9Q 9ENPaFNpogyG0T0TTIaDTQB6mjR6jQaNNqDQAaA0yBtQBiAANGmgNB6hkyA0DQYhoASpqIjRT9PS GjUzUynqeJNknjTUTyBqbTU9Gp4o9Ieao9Go008jSPKHqemp6mm1NGxRnqjZpTygGjymZE9CBk0D 1M1DaCeo2U9R6g9TRtIAGQ0yaDRp6gUvZ2LdmItO5BRpdR1T+1YIJYFzSgw87RbTGNVZvNTJNo/v wkCCIt9JUAsiAcWRG7vkc/p+ffRNUhRP7IAnFESRTKKhMumPSqc8Utyk4/uQE0RAS8NH3ihBkSEo CkLp+4ZABRXwK63K5Wkc8SCgwZQKCDbKgk4atnvh5P5jKiU5cRrQBwlnDr3gHgaH6V1MPVBkAJRV RJYrjRvcMALlMJkQrQDDufYA4/0lTXA4coJh2uZUJZAZ7ovvcP+LFNy8oegwUoN3IooKksEBKU1c JAYFGJBFKyYpJb6tWM4PhBBVgvwDFQ30YQKHsD8d68m68PgtHdvRaChQk8xLi4S0f5eCpBlKo7qW olITSKlaIUuFBA/R3S6GIM0ykycbuzrDGrnDY7Bm4WPXys3Jv88iETKkU+GdntuSCQ4U1MVBIyQK jBK65vwmvuevx1xob6YrC4MZjMr2YUETOIAPDVRc6pLkkeH1Tj1SJhiUAyEEE3ysEFn6iVS1JqGP qDBNMGBlsA1sa8cmfKWKZ2twI3wO8xiGBcABG7GASAqBUXKhUM7CotS5eGIDAVplhBy93o6DsxIT obNxVKHZ3tEzaEB71YIZ4Dof4qAhJzmlMgVxpIHgfDbe2IPKQkivBpw6NAiGC7wWWeCIiXFz6GEv uuojl9ZiNW1C4vXsxD51LQ74Gs+/bCwQMuDA4JE/ahIdLSLxDSZLE/J58InEUb3xOCBhqKmHM+/M iZ6TO0h1WYPTiW8rJXHM4IoaAGPoin/+5+LYog3oxZcYS83VFhRoxIQG7x98Pm2l6f+9ZnhiBORC SdWYWwIPU4FAg7N8b40RBhENcZde0PBo22HkwPFbr73kYvsV5IRim2pNYNC1LD5GcZUE8GcMn2dV dpUTVHB8mvKkv0/yh7Dmtq9Il5e1/KH/ZF2qN9XCNDIQOo16udaJBkbDeegf1snvcyoIG0Au/ZmA EONlSZUrZt73+6AKsAtgC9AXAp5lN5HDrsG95RUOY3zNehe3PTYFNoW3huDHACBTY0IUTkAzB6aY uJzNXvgA9qepUUwrj2Ny9dTWukdPTZjvh2TxhXCpQDNd3o3I9NCwjapv1pUUIK7zYPTKjm5GwdYw 9JFvous08ruzM50nFrnNLREBevAKIAuvR5+4oqo5VIeKBRoilIomXls/bxnmxKSSwPvnON0eSa3f hmYiJbaKObws+PX1aip0sSsoVcPe6aojrE6UUyTUTTdXdFsI7VLZjjeQAV2QFvijpM03B7p5+8vJ IYJAAs3qfUPKo8MBUQwA7Z6hCvkyaUyz+JNgfnq/NAXAIz4yzmAUyAQEAoDXqGvsNWBJpbAAGfSb l9xu94qyxoHdtk8rCgQuxvtpntlzUTDKcgMuAKEFDACJcWMwocT6FFVOBtoaSYB3aUW3NiO1FuSo dHEWoqNcTHCVVE56ABSDwGoE8G3qrMIgcF6XQy1dol/qnDs9bB2TvUtxNHw+PZIHhmMSAAKCHGYv MenmmlwxPVfBplAwUAAOK/UOQAVGFrDQACtB2c4qBCygAU52ZEmc1O4mWZyjWjXplKAF8o0e6tV8 5SPvUokp5rlA6iJPNN8ergGGBOz7LRgKd+rsIPZxzW/AEfKU7RSkt+vtv1fgOWnBQrACJAMvrHNd JRQBv4xQGNuY3/HEt+T04KK0yUFl5ERlp6paLsEs0tNKJNP9WLsuLYOYudmY2u0dAh6PlYvte5s3 ijIuCY6gQ1rGtoACn/NFIQA74hFIbq90T0NFMob+1jbMVDOEcvTtZY+wZZ591cqotm21KCFKjfTG C6ZDwEi5NVR/noSLo0oYGroV1ONk56c25BXQO585MCmMRDqZPL51h6rQ6Z0112tL8GkW3jpyOfqI aBCgFEvaJbP7DUmtcQBxYf6cbf2eEMgkbfhmiZSGtLUylbD5A/Jds7TkBgTCdrGdagUMYKpJOEh7 TzR8ojUOglxDBdcKBBx6ziJmUK+uAcIamllB0L+hXx8KqkbBrll/QdSABUUl0bqaDDYogAQZf+fT MF/Ms6/+j5qF8O0FlSvoxX3n2CL2vVmuKYc0qBSH56lSWKJmdCwiLiosFNRGcCrrJD9Ch2SD/M4K PHeWjvf8jTDZQ4852X8+499w6nOrzN5vbbPqF9eJctpDopy2t2cdZ1FpG/G2rkFBM568w0KiblGs JKPTQh2eVu6wdOac96RDtO6MAFa0JfVaZhsYYYaLGAH0AZTx6zeLSln1yJLuscwslUWxDOVUnlNQ QMYRaYnr2hbOHH/XR1eb3EKwrWaV6g/zsgZC9AUBn9+V0GgRWwoNI9mlUd+zYRtBc56/yE8IkWid 0ID/4Nc6AwK28UBnwDSBoAMQDOcWsKhFFcSF0WkvNFb3exJ/jtbWwsmFtGAXc7vby1ANbk9+49Qy WZwYdUn7K5tEfmfNgFw6AEYAQAAlAtjZU/2RGR6t7u3lW3coTR6ITTSZoM2CCo1zCXvTBpFEon4Y CLAOBtY5g5EyBCoCitEVcsVEDhhAY+W2d+uvKIp+Ap7JJ78ZQK8AyOXAacCb1yKyyFGm47yuc9t6 38PABYAoV8pDUFWBMqAx0VI6mn4mhfYXOGrsJHiYvhQgEeCjbyABPAHCluQgmikbmdYy138yogyt HoGwnd3HmbJZtMtrpx6SbuQAb2j6vtEBY4DSrlhEEE2tklggidygSM4tGXawwjRBfXYbY3fQAZDF hgCm1IKGAURcr0N3kqgB/UAec8GXS5UuIP7MK3Xf8HYXzPrspIz4BFxwPEVH1ztdkig6dIO1fVre MAdbKBgiUdNuVG/pJVKgI2P19SvaAC9I3waTq+38dUxG/tHg9BQ6B+QAlwDet2ogBDgDQDugNJAv dvgvIMsW7GnhCsAIqzAFyCBYAkNFw+PuKows44Hzkq0DHgQoKGp/PGLqHhQBoAUn/c85mOE2hC+g Nt76KlW4KIzlgyN4zWPMTWopUuim3Ji/AnGX32fJ/vnaW9qHLkAyMrY7a/WZZaJxcXQiBAABOHSZ j2gHENlyIScBQcWYsOQOWEhXnNMStQ8o7xJ1D4F90le4uMGip3E+cKpkuVm27SLV/SSSd9T1trgo bK3m0sNsHbaqXFFINm0kaqL3Ye/7xm/d5vlyittZWfA8JaZyxwmr6KafFCUUOWXQqKWW1Nskj+wN eNeMKzJEOg1zJ4r89fEgCl7msJUtFbGBzSIE3fFTK8dxRATZdwaIQf7OfJB9pwNbn1TSCWq0/u0k J0HO7ZTcOMLG3TH4cn7uJCKP+l5Nx76rblGf0JivxR128xto4InWItli4iiBtWwizC6sauM6eZii rGl7eUini0wjq1kO/Oxl7fCxbOAOrMxBJmyHchgSPJwgX8IP38KNJej1cXW1HdMgL6EaPom+xX95 O1ozq5Wu1S/9o7fYhTXYjpSbR4YqVmO3f+ZZGEcKZWZj3KDQZdfg4l5awy3rens25jbzBs/AcZIi RWAy8zQPMXEwKJzNkVCUOgAXP59yalRlgJWRDGyTZXEJSRhMD+kq/PaJ1kIqaKEDASd9dKqwZNrW HfW8T4SC5h+mrhesVGOfdjuF4u/FL9PRy6ibat6pw71sbouegF85Kh73J0kgzX3xrKJl3xl68nnt ujQlNNvqYlhv6fGJ2+zyTnSRFKIyfHI+ailIqVVU90YnIQwFlOLfDj2Sw9exKTkxyelEjSM5G/4f XGj0n6NPMhLq/y+xlkcWmsctEQgG5KBTXMh3j5p0RghCC2cNSK7nWpkGNht6BA8UhXqHvv1Tnppj nJkhUraNcQsUuZbPYxW7WOsQ2K0OMk0sOAE0W0Zkh6/Jdpg5nswJH0HVSXAaf5b1uPq+d2G1yzkq Z6jkBmzqClrmfFhy3ntIt73qyH+MlVd/q1ABIEAy0VM7mOOGZX+zBP1ZnGx48yrxEKE45z4EE4Ig un6v9MTueMJljdzoyuE5cxlB18VHKJVepinVOi0E4VwfZxkIXQQAmFLKlrgrykPFh5DhZGJVHZ8D BABoQLBwNWmEmpHpHw2dk+/bunKaPCcEZlJAlAWgpUdBLrAdkW60gpaeFuHzg6dw6oaTIow3MX4u 0tRwUGyPmy3A9M0Usy0KF2hxwnBAFMfIA0SMmEMBDGLfunlaV2AcW1FQxx8UrnFqBjXLu/IPsjA9 g+5v71Jm6s8PvW11IhCZQq+NCzaVtfc0YQf0RRhNFjYmatLTMRvmbuwTS7g3EZVc78UQmBBkjqv7 csnkOqTtEmtl8LSpRC5hhQGwDAmkWaAq0QWvtnpmPUimYYiDp77MSXUwKTXr6K/UTdx2pk/WcOfd glk9I/xiRGrI/jQ2zNzPuIMDdRZkQTFAlcRLEqtqMs8uACBujyeC8G21hgUcrkztMirhhCvZgMAU Ozrcecqe56ZqjIopvDTYO8/vq7uljNbdF2FKSwyBhgcgwHYqd9RN6eLvPBKR9HIT3Dhdsios6DXn JjvODAVZnb+W9NUeWov9a2XddXOuLBd9vBvnz5PE6+1Gfm8Rb6CzeCc0/x2xyHS4h4IpzVIpCAkB vEbOiKNj22kZpzjXJA+boNtWOLMLwu5aM+gKAYIVRG1RIWDpWe5VMNgD1OIz8034tdpgRuI5bEK1 hWK08FTkKpUdMV4p4S5StupsB3rq9LoYj+AgsR9nAjmm/qpYlgp8eTYmLZeyL41jrZGwea7hAqoJ JelO9cKHJpBb7YtNREW2af7UngfCkgHy0yhx1rJYW9szMGzeq2DWP3OcSz+xYKH+489bubmLnzx/ SMb9stCOtkxQbEs4UYYKQpQAUFienhMEjzGMlPUO5rx16zXquWvci8At2svVsyYY3hn5V5WnIRWV /qS/R4SUmRewmEb8pka/cXq+L64dN128k8IgUKa1obhHombNOdGwuPSSCxkpXfNRLwpCbbA7KDkP WTPIXvDaL4CPSUsNuYDptd/Humcx6y6dbZjNo4C4kTPUOyna7LJwD/FWh0qpKC75afvrkhe7TJt8 dU1cp5aVaAKWYVhUD1JDlvVyc1VsQcup5nnpodFqYbsFetZCO7PFnX5VlxnhODeWmvKw1LgIMrHy KJt8U9BSf+LuSKcKEhfAzWpg