Bug 99703

Summary: [chromium] Add additional memory management fields to WebGraphicsContext3D
Product: WebKit Reporter: Christopher Cameron <ccameron>
Component: New BugsAssignee: Nobody <webkit-unassigned>
Status: RESOLVED FIXED    
Severity: Normal CC: abarth, dglazkov, enne, fishd, jamesr, tkent+wkapi, webkit.review.bot
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Unspecified   
Attachments:
Description Flags
Patch
none
Patch
none
Patch none

Christopher Cameron
Reported 2012-10-18 02:57:03 PDT
[chromium] Add additional memory management fields to WebGraphicsContext3D
Attachments
Patch (5.53 KB, patch)
2012-10-18 03:02 PDT, Christopher Cameron
no flags
Patch (5.60 KB, patch)
2012-10-18 03:22 PDT, Christopher Cameron
no flags
Patch (7.33 KB, patch)
2012-10-23 12:14 PDT, Christopher Cameron
no flags
Christopher Cameron
Comment 1 2012-10-18 03:02:09 PDT
Christopher Cameron
Comment 2 2012-10-18 03:03:43 PDT
Comment on attachment 169378 [details] Patch Add new fields to WebGraphicsMemoryAllocation to allow for specifying limits for when visible and not, and to allow for specifying priority cutoffs (e.g, to allow specifying that backgrounded tabs should retain only their visible textures). Add sendManagedMemoryStatsCHROMIUM to WebGraphicsContext3D, and add WebGraphicsManagedMemoryStats structure, to allow the GPU memory manager to make more informed choices.
WebKit Review Bot
Comment 3 2012-10-18 03:04:53 PDT
Please wait for approval from abarth@webkit.org, dglazkov@chromium.org, fishd@chromium.org, jamesr@chromium.org or tkent@chromium.org before submitting, as this patch contains changes to the Chromium public API. See also https://trac.webkit.org/wiki/ChromiumWebKitAPI.
Christopher Cameron
Comment 4 2012-10-18 03:16:24 PDT
Some additional context: The old fields of the structure, gpuResourceSizeInBytes and suggestHaveBackbuffer are left in place so that this can roll in and not break anything. When I've changed the Chromium side, I'll delete these variables. I put a some extra things into these structures (in particular, the allocation counter and acks) in case they are helpful. If, when I have the whole thing wired up, they aren't helpful, I'll get rid of them (along with the deprecated fields). The strategy here is to avoid iterating in both WebKit and Chromium.
Christopher Cameron
Comment 5 2012-10-18 03:22:21 PDT
Christopher Cameron
Comment 6 2012-10-22 16:12:22 PDT
Ping.
James Robinson
Comment 7 2012-10-22 18:50:49 PDT
Comment on attachment 169383 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=169383&action=review I really dislike adding things "just in case". Let's figure out what we actually need and do that. If we don't know whether we need something yet, we definitely do not. > Source/Platform/chromium/public/WebGraphicsMemoryAllocation.h:92 > +struct WebGraphicsManagedMemoryStats { WebKit API requires one header per type. see http://trac.webkit.org/wiki/ChromiumWebKitAPI
Christopher Cameron
Comment 8 2012-10-23 12:14:30 PDT
Christopher Cameron
Comment 9 2012-10-23 12:19:16 PDT
I've put the structures in separate files. I've removed the counter/ack from the patch. I think it's fairly likely that these will be used in testing (if not in actual policy), but we can burn that bridge when we get there. All other fields have concrete plans to be used.
Christopher Cameron
Comment 10 2012-10-25 10:16:20 PDT
Ping.
Christopher Cameron
Comment 11 2012-10-26 10:39:01 PDT
Ping. I'd like to get this in before M24 branches.
James Robinson
Comment 12 2012-10-26 12:34:33 PDT
Comment on attachment 170204 [details] Patch R=me
WebKit Review Bot
Comment 13 2012-10-26 12:58:20 PDT
Comment on attachment 170204 [details] Patch Clearing flags on attachment: 170204 Committed r132686: <http://trac.webkit.org/changeset/132686>
WebKit Review Bot
Comment 14 2012-10-26 12:58:24 PDT
All reviewed patches have been landed. Closing bug.
Note You need to log in before you can comment on or make changes to this bug.