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

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Fri Jun 11 06:41:30 PDT 2010


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





--- Comment #6 from Alejandro G. Castro <alex at igalia.com>  2010-06-11 06:41:29 PST ---
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?

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.

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

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.

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



More information about the webkit-unassigned mailing list