Bug 218259

Created attachment 412478 [details] For EWS

(whoops, looks like I missed a SPECIALIZE_TYPE_TRAITS_DISPLAYLIST_ITEM for SetInlineFillGradient in this patch)

Created attachment 412486 [details] Fix builds

Committed r269092: <https://trac.webkit.org/changeset/269092> All reviewed patches have been landed. Closing bug and clearing flags on attachment 412486 [details].

<rdar://problem/70748246>

Since I don't recall seeing any references to what [Concurrent display lists] are, can you please explain what this feature is, and how you intend to go about implementing it?

(In reply to Sam Weinig from comment #7) > Since I don't recall seeing any references to what [Concurrent display > lists] are, can you please explain what this feature is, and how you intend > to go about implementing it? This "feature" is supporting concurrent generation of display list items in the web process and consumption of display list items in the GPU process. Our overarching vision to achieve this is to make all of our display list items contain only PoD types, and store them directly in memory shared between the web and GPU processes. Upon pushing items into shared memory in the web process, the web process will notify the GPU process, which will read items out of shared memory (and continue doing so until there are no more items left to be read).

(In reply to Wenson Hsieh from comment #8) > (In reply to Sam Weinig from comment #7) > > Since I don't recall seeing any references to what [Concurrent display > > lists] are, can you please explain what this feature is, and how you intend > > to go about implementing it? > > This "feature" is supporting concurrent generation of display list items in > the web process and consumption of display list items in the GPU process. > > Our overarching vision to achieve this is to make all of our display list > items contain only PoD types, and store them directly in memory shared > between the web and GPU processes. > > Upon pushing items into shared memory in the web process, the web process > will notify the GPU process, which will read items out of shared memory (and > continue doing so until there are no more items left to be read). Sounds reasonable. What is the plan for things that can't be directly encoded, like IOSurfaces?

(In reply to Sam Weinig from comment #9) > (In reply to Wenson Hsieh from comment #8) > > (In reply to Sam Weinig from comment #7) > > > Since I don't recall seeing any references to what [Concurrent display > > > lists] are, can you please explain what this feature is, and how you intend > > > to go about implementing it? > > > > This "feature" is supporting concurrent generation of display list items in > > the web process and consumption of display list items in the GPU process. > > > > Our overarching vision to achieve this is to make all of our display list > > items contain only PoD types, and store them directly in memory shared > > between the web and GPU processes. > > > > Upon pushing items into shared memory in the web process, the web process > > will notify the GPU process, which will read items out of shared memory (and > > continue doing so until there are no more items left to be read). > > Sounds reasonable. What is the plan for things that can't be directly > encoded, like IOSurfaces? I would think IOSurfaces would exist in the GPUP already, so an identifier (and possibly some additional metadata) should be sufficient. More generally, our current thinking is to add a special display list item that represents mapping an identifier to a resource encoded directly in shared memory, and making display list items reference the resource via the identifier.