[Webkit-unassigned] [Bug 39582] [Gtk] very slow page scrolling on big -webkit-box-shadow areas

[bugzilla-daemon at webkit.org]

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


Dirk Schulze <krit at webkit.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |oliver at apple.com




--- Comment #7 from Dirk Schulze <krit at webkit.org>  2010-06-11 07:42:15 PST ---
(In reply to comment #6)
> I've done some tests these days checking the proposed solution but it has one issue that I think can not be solved generally. Basically when blur deviation is big enough the blur converts the squares in a kind-of blur ellipse and we can not use it to do the tiling anymore, that means that the blurred rect size will depend on the deviation and the piece of shadow we get for the tiling could not be correct (rounded corners could not be reduced easily either). Or another option would be to do this when devitation is under a value. Not sure what function describes that relationship between the deviation and the size. What do you think Dirk?
This is not the normal case and we can't do anything against it, if the user takes this huge deviations. Rounded corners would need bigger pieces for 1,3,6,8 but shouldn't be a problem to determine the sizes.
We should also have a algorihm to determine the size of a blurred object already. We need it to get the smallest size for the temporary ImageBuffer right now.

> 
> I was thinking that instead of reducing the shape we could reduce the blurring area. Currently, as Dirk said, it is being used the whole size of the boxes, we can clip it with the viewport, and we could even use a part of the surface depending on the offsets of the shadows and the deviation, doing 4 blur operations:
> 
>     1
> ---------
>  |    |
> 4|    |2
>  |    |
> ------|
>    3  |
> 
> Or just 2 in case the offset is big enough compared to the offset, this could be used for other shapes.
How can this be faster than using a smaller shape area? You just need to determine the size of the rounded corners after the blurring, and calculate the size size of the shape, so that you have at least 1 pixel for the straight edge for every side. The most blurring operations have a kernel-size < 20 px, so that in most cases the resulting tempImageBuffer won't be bigger than ~ 100x100 pixel (I bet the avarage case will be smaller than 30x30 pixel).
After that, you cut the tempImage into different pieces and fill the area of the original shadow with different patterns. Just like CSS's border-image is doing it (http://www.css3.info/preview/border-image/). You even don't need to rewrite the code, we already have the code. See Image::drawPattern(...)

> 
> Anyway, checking the solution I found a couple of things that could help us:
> 
> 1- The one proposed before, use the data instead the getters and setters in the blur function, I meassured 20% performance win with this. http://pastebin.com/NNR005sm
Sounds reasonable, but I'm not sure if there were security reasons not to do it that way. Oliver can you take a look at this please?

> 
> 2- In case of alpha-only, avoid getpremultiplied/putpremultiplied and use the alpha information directly from the imagedata, maybe we would have to add API to get this data. Those parts of the process represent almost 40% of the time with the patch of the point 1.
Cairo stores all values in cairo_surface_t as premultiplied. That means, getpremultiplied/putpremultiplied are just copying the values from the surface to the CanvasPixelArray. How do you want to get the values without using  getpremultiplied/putpremultiplied? I just know one way, implementing it for cairo again instead of reusing already existing code and optimize the realy relevant part: making the blurred area as small as possible.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.