[Webkit-unassigned] [Bug 95758] [chromium] Adjust texture priorities in preparation of impl-thread eviction of only some textures
bugzilla-daemon at webkit.org
bugzilla-daemon at webkit.org
Tue Sep 4 18:14:05 PDT 2012
https://bugs.webkit.org/show_bug.cgi?id=95758
Eric Penner <epenner at chromium.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #162121|1 |0
is obsolete| |
--- Comment #9 from Eric Penner <epenner at chromium.org> 2012-09-04 18:14:18 PST ---
(From update of attachment 162121)
View in context: https://bugs.webkit.org/attachment.cgi?id=162121&action=review
>>> Source/WebCore/platform/graphics/chromium/cc/CCPriorityCalculator.cpp:54
>>> +static const int kFarFromVisibleBase = 300050;
>>
>> Could we possibly just squash these into the above lingering group? There could be many lingering textures (enough to use all remaining memory) and I would rather not have them take away memory from closer textures. Could we just start calling all textures lingering after a certain distance limit is reached?
>
> I've moved them to be lower than than the >2-viewports-away but still higher than <2-viewports-away. I'd like to keep lingering to be closer than "many viewports away". There is a pathology now where on very long pages, we will use all available memory caching very-far-away tiles, and I want to keep the lingering tiles with higher priority than the very-far-away tiles,
I see the issue, but doesn't this just push the problem to the lingering tiles? There could be unbounded lingering tiles as well which would consume all memory, including the 'far' tile memory (which would more likely be closer than the lingering tiles).
What about setting the limit to be some multiple * visibleMemory, to reduce the total memory usage. This will mimic and LRU since all lingering tiles slowly decrease in priority.
In any case sorry about the 'lingering' thing! Lingering will go away soon!!
>>> Source/WebCore/platform/graphics/chromium/cc/CCPriorityCalculator.cpp:100
>>> + {
>>
>> Could we call the manhattanDistance function here and then normalize to viewport units? I feel it's more clear what the code is doing that way.
>
> I wanted to do this, but the normalization is different in X and Y (so I can't recover it directly from the scalar distance). I've added a comment about L1 norms because it's you're right that it's unclear what the math does without that prior.
Hmm, how about reducing to one viewport scaler (average or sum?). In particular a wide viewport shouldn't bias towards caching horizontal tiles.
--
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