Bug 86764 – [chromium] Limiting render surface texture manager memory to 0 when contentsMemoryUseBytes is large.

• Status: RESOLVED
• Resolution: FIXED
• Component: New Bugs

[Michal Mocny]

[chromium] Limiting render surface texture manager memory to 0 when contentsMemoryUseBytes is large.

[Michal Mocny]

Created attachment 142520 [details]
Patch

[Michal Mocny]

Patch fixes a bug where renderSurfaceTextureManager memory set to a large value due to unchecked unsigned subtraction.  contentsMemoryUseBytes can be higher than TextureManager::highLimitBytes when memory limits are increased.

There is an open issue to improve synchronization between render surface texture manager and contents surface texture manager.

[Adrienne Walker]

Comment on attachment 142520 [details]
Patch

Eep.  R=me.  Can you explain a little bit more how we get into this situation? If the memory limit is increased, why does maxLimit not represent that?

[Michal Mocny]

Sure, highLimitBytes is a static function that returns a hard coded limit based on viewport size.  LRC doesn't actually have access to contents TextureManager so it cannot query to actually current max memory limit.

Instead, it uses the conservative lower limit of assuming the default.

However, contentsTextureAllocator tracks texture memory usage and is used by LRC to get the actual current usage, which can now be higher than the default maximum.

[WebKit Review Bot]

Comment on attachment 142520 [details]
Patch

Clearing flags on attachment: 142520

Committed r117485: <http://trac.webkit.org/changeset/117485>

[WebKit Review Bot]

All reviewed patches have been landed.  Closing bug.