See this profile: https://perfht.ml/2l12Pzj Here is what I did: I loaded <https://docs.google.com/presentation/d/1gqQpeG1vHky4nZ45mIYSC5DAEFX-5HipjemLwhBDe1c/edit?pli=1> in a tab (needs LDAP login) and waited for it to be fully loaded, and then after a while I clicked on the thumbnail for slide 5. We spend ~450ms in SkScan::AntiFillRect.
This is interesting. The operation should be quite fast (some approximation of memset). Maybe it's doing it a large freshly allocated buffer? I wasn't able to reproduce the problem when trying to profile in instruments.
I cannot reproduce it either. In your profile it's drawing a background color display item, which is probably the first item to draw to that part of the memory. So it could be drawing to a fresh tile and waiting to page in (or zero-fill-on-demand) that piece of memory.
I tried to reproduce again on the document that I have left open since yesterday: https://perfht.ml/2mbPwBc Only 76ms here. Another time, immediately after a reload: https://perfht.ml/2mbPQQq Only 56ms here. Could there be a bug which only causes this to take a long time in some cases?
IIRC our tile pool starts discarding tiles after a time, and if you encounter a page that has more or bigger layers and needs to allocate new tiles, you're more likely to hit this bug.
8 months ago
(In reply to Markus Stange [:mstange] from comment #4) > IIRC our tile pool starts discarding tiles after a time, and if you > encounter a page that has more or bigger layers and needs to allocate new > tiles, you're more likely to hit this bug. Markus, is there more investigation needed here?
Maybe, but I think whoever looks at the tile pool next should focus their attention on bugs like bug 1346365 first.