[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 #18 from Eric Penner <epenner at chromium.org>  2012-09-10 12:51:30 PST ---
(From update of attachment 163177)
View in context: https://bugs.webkit.org/attachment.cgi?id=163177&action=review

I know we'll need to copy priorities to backings so that's good, but I think it would be ideal if we could limit things such that we can think of everything as always being 'up-to-date' rather than thinking about 'AtLastPriorityUpdate' values as that introduces thinking about threading etc again.

Is there anything wrong with just keeping the old lazy scheme and sorting/copying priorities over during the lazy sort step? Those values should always be up-to-date. My first preference would be to just insure sortBackings is *always* called externally when it needs to be called (after any main thread involvement), but your case above illustrates that's not as simple as I thought.

> Source/WebCore/platform/graphics/chromium/cc/CCPrioritizedTextureManager.cpp:225
> +    ASSERT(CCProxy::isImplThread() && CCProxy::isMainThreadBlocked());

Are the backings possibly not fully sorted when this is called? Could this miss available backings if they were high priority but were since returned?

In this sense I preferred the old lazy scheme which always detected and kept the backings sorted, or in alternate just insuring sortBackings is called everywhere it needs to be called so this would not be needed.

> Source/WebCore/platform/graphics/chromium/cc/CCPrioritizedTextureManager.h:108
> +        if (priorityA == priorityB) {

Minor nit, Google usually prefers minimum nesting with early returns, eg:
if (priorityA != priorityB)
   return priorityIsLower(priorityA, priorityB)
if (aboveCuffoffA != aboveCutoffB)
   return aboveCutoffB;
return a < b;

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