[Webkit-unassigned] [Bug 96114] [chromium] Make prioritized texture manager not touch backings array on the main thread

[bugzilla-daemon at webkit.org]

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





--- Comment #14 from Christopher Cameron <ccameron at chromium.org>  2012-09-09 23:15:22 PST ---
(In reply to comment #13)
> (In reply to comment #12)
> An another option (could go either way really) we could always make the sort explicit in the commit and remove the lazy sort flag. It would make it harder to accidentally not sort IMO, but also reduces flexibility a bit I guess.

I liked this idea too, but it kept on blowing up when I had the sequence

  main thread               | impl thread
  -----------------------------------------------------------------
  beginFrame                |
  - prioritizeTextures [A]  |
  - (block on impl thread)  | beginFrameCompleteOnImplThread
                            | - prioritizeBackings [B]
                            | - un-block main thread
  beginFrame                |
  - prioritizeTextures [C]  |
  - (block on impl thread)  | scheduledActionUpdateMoreResources
                            | - acquireBackingIfNeeded (**)

At the point of the (**), the backings vector is sorted based on the priorities at point [A], but when we check the backings' orders, they are now out-of-order with respect to the priorities at point [C].  And note that at step [C], we may have unlinked backings from textures, so the inconsistency is not just in the priority values.

Now, we will need to (very soon) push the priority values to the backings themselves, in order to delete only-some textures on the impl thread.  So one solution is to push this data to the impl thread at the "prioritizeBackings" phase.

The down-side to this is that it opens up the possibility for a performance regression: As of now, the PTM can, by virtue of this race, recycle the backing for a texture that it knows will be deleted in the next frame that will be committed.  With this change, the PTM would lose this ability.  As it happens, this happens a lot every time we load a page (in particular, for a simple page, we hit the recycle queue 42 times on page load with this behavior, and 31 times if we regress this behavior).

Anyway, I've put together a patch which
- pushes the priorities to the PTM at only commit time in the ordinary run of things
- re-pushes the priorities when we fail to find a hit in the recycle pool *and* the the main thread has returned some backing(s) to the recycle pool since the last push

I'll attach the patch when it's cleaned up enough.  Of note is that we're (necessarily) pushing more into the "separate main and impl" territory that enne mentioned (and that will become unnecessary when we have impl-side painting).

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