|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>|
|Severity:||Normal||CC:||cc-bugs, enne, jamesr, nduca, webkit.review.bot|
|Version:||528+ (Nightly build)|
Description Michal Mocny 2012-05-17 11:55:01 PDT
[chromium] Limiting render surface texture manager memory to 0 when contentsMemoryUseBytes is large.
Comment 2 Michal Mocny 2012-05-17 11:57:43 PDT
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 3 Adrienne Walker 2012-05-17 12:03:12 PDT
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?
Comment 4 Michal Mocny 2012-05-17 12:07:59 PDT
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 5 WebKit Review Bot 2012-05-17 13:03:23 PDT
Comment on attachment 142520 [details] Patch Clearing flags on attachment: 142520 Committed r117485: <http://trac.webkit.org/changeset/117485>
Comment 6 WebKit Review Bot 2012-05-17 13:03:29 PDT
All reviewed patches have been landed. Closing bug.