| Summary: | [chromium] Limiting render surface texture manager memory to 0 when contentsMemoryUseBytes is large. | ||||||
|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | Michal Mocny <mmocny> | ||||
| Component: | New Bugs | Assignee: | Michal Mocny <mmocny> | ||||
| Status: | RESOLVED FIXED | ||||||
| Severity: | Normal | CC: | cc-bugs, enne, jamesr, nduca, webkit.review.bot | ||||
| Priority: | P2 | ||||||
| Version: | 528+ (Nightly build) | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Attachments: |
|
||||||
|
Description
Michal Mocny
2012-05-17 11:55:01 PDT
Created attachment 142520 [details]
Patch
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. 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?
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. Comment on attachment 142520 [details] Patch Clearing flags on attachment: 142520 Committed r117485: <http://trac.webkit.org/changeset/117485> All reviewed patches have been landed. Closing bug. |